skysight-inc/HackerNews huggingface dataset:
The Linux kernel is fairly modular, I could definitely imagine rewriting subsystems by subsystems with fairly good ergonomics and safety. Like rewrite serial_core.c in Rust and then let people write serial drivers in Rust. Then the SPI code. Then the I2C. Then USB etc...

Easier said than done of course, and definitely a huge effort especially for such a huge project as the Linux kernel, but there's also a significant amount of resources that could be allocated to that task by several large institutions.

I don't know if it's a good idea, or if ATS or something else could be better, but I think you're overly pessimistic.

Also "the safety guarantees that Rust provides are neither unique nor complete", while technically true, is also borderline FUD-y. At least you should expand on what you have in mind here, because I doubt that there exists a programing language that deals with low level hardware configuration that could ever provide "complete guarantees" about anything.

And beyond that, keep in mind that Rust provides a lot more than just safety guarantees, its syntax is lot more advanced that good old C in particular for anything dealing with types (including destructuring, matching, inference etc...). Even if you don't get "full" safety right away it can still be a much nicer language to code in (and I say that as somebody who knows C well and quite like it overall).
The comments on that article (and a few in here), are lamenting the churn and loss of addresses due to the whims of the market. People holding onto email addresses like precious items. It's surprisingly affordable to just have your own domain!

I won't get into other core benefits of paying for mail (no ads, business model where you're the customer, etc). But...

You can

- have a personal domain and email address for as low as $15/yr (weird tld, small mailbox)

- have something more reasonable (domain+email for $45-65 a year with 20-30GB + various PIM functionality depending on provider and price)

- go all the way up to fully hosted personal cloud solution via something like Microsoft365 ($150/yr)

- self host everything yourself - $7-15/yr for the domain

If you use email heavily, and/or if you value having the option to self-host more things, then it's absolutely worth it.

Personally, I self-host my cloud drive with a freenas box in a very close to default configuration, and use Fastmail for mail+PIM.

If my provider starts sucking, I can switch easily. The more paranoid could use the more expensive protonmail or fully self-host! But what's important is that should I ever choose to switch, it will be a one-and-done thing that probably takes me about an hour of work!
* The IDE/Debugger rocked. It was the killer app. You could explore/understand code in a way that I have yet to see rivaled in any other environment. I have used PyCharm/XCode/Studio/VSCode/Emacs/Vim at regular levels.

* BlockClosures. Reified and used ubiquitously. Did I mention reified? Since the language had no control flow builtins/keywords, it was all done in the library. And since Closures were fully first class objects that you could explore, understand, and extend, you could write control flow to your hearts content.

* Simplicity. You didn't have to have a PHD in parsing to deal with the AST for Smalltalk. Building your own AST walker was a mid level exercise. I once saw a comparison between the Ruby AST and the Smalltalk AST. The Ruby one was like 10 times more complex to deal with all of the edge cases. I added a goto implementation for a lark in an afternoon. I wouldn't even know where to start to add goto to Python. An absurd example of course, but it highlights that you didn't feel like Dan Ingalls and the other inventors of Smalltalk controlled your destiny. They wanted you to go places with it.
If the runway does happen to have ILS, there's another authoritative source of information too.
If there is any amount of water, It could be life or life remains trapped on it. Maybe not based in cells, but other forms like viruses... Hum.

Is a really intriguing discovery. Maybe supporting the panspermia theory. Maybe leading to one of the biggest discoveries in our recent history. Maybe they could find several types of ice, if they came from different comets.

I hope that we could analyze this water before to burn it as fuel.
But Android allows side-loading and hence cannot reject apps. So, consumers can get all the apps they want (insofar as they exist) by buying Android devices.

I guess Apple would argue that their policy to reject apps doesn’t hurt consumers, because, if it did increase prices and/or decrease quality and/or decrease availability of apps on iOS, why do so many consumers still buy iPhones? Maybe because having only one, vetted, store has value to them, too?

(Just to make sure: I’m not sure whether I would buy that argument, but I also don’t think it is a slam-dunk that Apple’s behavior hurts consumers, and that consumers have no choice to accept that (there’s nothing against companies giving their customers a bad deal, as long as they’re free to walk away))
If the problem is change then you will always have problems.
My worry is that once these things are fully automated and planes are no longer manned this will also create an infrastructure for future 9/11 like attacks.
I was able to switch to vscode from webstorm recently, this was mostly due to incorrect ctrl click navigation in my webstorm project.

One thing i miss is the version ctrl and diffing tools of webstorm
An apartment complex I lived in was fined tens of thousands of dollars for improper waste sorting. This incented the complex staff to at least invest heavily in education and installed new cameras next to the dumpsters...
I’ve used ATS, Idris and Rust, and I find ATS way more cumbersome to use for writing proofs than idris.

I’ve never used ATS to do what the GP is suggesting of incrementally wrapping C with proofs, but I can’t imagine this being simpler than just rewriting the C in Rust. You wouldn’t get the same proofs, but you would get memory and thread safety, which for many apps would be an incremental improvement.

I haven’t taught ATS, but I found it harder to learn than Idris, and I can’t imagine C programmers which have a hard time with Rust learning it quicker than they would learn Idris or Rust.
As an occasional rust programmer: you don't see this kind of behavior from the rust community. You see it when a random person opens an issue on a bugtracker you are subscribed to. Then it's usually prompty closed by a maintainer because the issue is very low effort, and the author doesn't offer to do any work themselves.

Examples: https://gitlab.com/fdroid/fdroidclient/-/issues/1049 and https://github.com/rapid7/metasploit-framework/issues/9092
Even if they don't, say goodbye to being able to purchase anything from Apple ever again.
Pointing out that you don't technically own the money in your conventional bank's chequing account is a mere distraction from the fact that in the real world, it's easier to permanently lose access to your cryptocurrency than it is to permanently lose access to your bank account.
It doesn't "just work". There are multiple significant design defects which result in absolutely atrocious performance in many common scenarios, or even stop the file system from working. These haven't been addressed.

The RAID5/6 issues are significant, but don't pretend that Btrfs would be OK if these problems were resolved. There are still many others waiting to be fixed as well.
BFCM is gonna be cray on this year. On brand for 2020.
I wonder if there is any data on how upzoning affects suburban property values. I would prefer not to live in a single family detached house next to condos. Then again, the optionality to put 10+ units on a lot has to be worth something.
I literally camped out the refurbished macs section until I found the specs I wanted without the Touch Bar. Took like 4 months, but I got it cheaper than new so it was worth it IMO
Actually, modern warframe is all about completing missions while using less bombs and planes. Killing residents may cripple the economy of your enemy but finding the high value targets and only bombing those is cheaper and more effective.
It is a selectively enforced requirement.
There is an element of truth in what you say, but it's not wholly true. We aren't as much a slave to conditioning as you say - especially when the stimulus disappears for an extended period.
[pilot here]

There's a lot more to managing planes in bad weather than landing them: you can't exactly fly through a thunderstorm.

Furthermore, sometimes go/no-go decisions have to be made a long way out. If it looks like there might be lots of thunderstorms near your destination, it's sometimes prudent to divert immediately rather than risk being near an airport with weather too bad to land AND low fuel.

A great example is a youtube video by stevo1kinevo: he's flying a TBM 850 (fast turboprop) from Florida to Boston International. While checking the weather enroute he decides the chance of storms near Boston is too high, and with the complexity of getting in and out of a major airport, he decides well in advance to divert to an airport on Long Island. This sort of stuff happens all the time and is the very definition of good airmanship.

https://www.youtube.com/watch?v=PZzOsXya4zw
I’d like to correct the record here a bit. Although Clementine, the first spacecraft to sense water ice on the moon, was indeed funded by NASA (and the Ballistic Missile Defense Organization), it was in fact designed, built, and operated by my senior colleagues at the US Naval Research Laboratory. For some reason NRL rarely gets mentioned in this story even though it was our spacecraft!

https://www.nrl.navy.mil/clementine/
Just a shorthand to indicate that it needs to decay faster than the harmonic series
> If you can't equally mock and ridicule every non-Christian religion (atheism included), then yes the Christians are being oppressed.

Your assertion makes no sense at all. Just because some authoritarian religious groups oppress those who may criticize them or their religion, do you honestly believe your religion is being oppressed if anyone cracks a joke at it?

That makes as much sense as claiming that your political party is oppressed by the press just because the Chinese and Russian regimes murder journalists.
People sometimes run code written, or even compiled, by somebody else. Strange but true. ("At least I think it's strange, and I am assured it is true." -- DA)
That's a great point. It isn't. We just blog about it. Let me bring it up with the team.
> I recommend that everyone use the “suggestion” box to suggest removing App Review entirely.

Probably not worth paying 99 USD/year just to make such a suggestion.

Just for those folks who aren't aware that you actually have to pay Apple every year for the "privilege" of having your app submissions rejected for such random reasons -- even if your app is entirely free and non-commercial.
Citation needed. Sounding plausible doesn't mean it happens or happens frequently. Most likely there are small number of cases that fit into this description - after all, wikipedia has 54 million articles. But I won't believe there's meaningful number of such cases, unless I see an evidence to the contrary.
I think we (mostly) have the emphasis backwards, and that this is part of your discomfort. We like to focus on the artist, art-object, art-process, art-technique, art-tools, and art-temples.

I think it all makes more sense if you focus on the art-experience.

It is OK for something that wasn't intended as art--like a torn sign, or a true accidental technical glitch--to trigger an art-experience for you. It is OK if knowing--or not-knowing--details about a technique, technology, or process affects whether you have an art experience.
I have almost no apps on my iPhone, and rarely use it other than calls, text, News, photos and maps. When I use it for web surfing, which is how I access News, I use Firefox, not Safari.

As for myself, I decided from the start not to develop "apps" for iOS or Android and instead keep building "web apps" instead. My apps are all business tools so I really don't need any special access or permissions to make them usable.

I will say LocalStorage sucks and I wasted too much time trying to make it not suck. In the end I gave up so Apple's and others decisions to stomp on it won't really affect me or my apps' users.

But Local-First assets and data management are something that developers will have to demand and there seems to be little thrust for that right now. Still, the shine is most certainly wearing off the hype developers were attracted by for these platforms so we might start seeing some movement that direction soon now.

I've been working on a local-first, offline-first, web app for desktop PCs that uses CouchDB installed on the user's PC instead of a CouchDB in the Cloud. Used this way with a web app CouchDB is somewhat akin to a sandboxed runtime engine for web apps on the client side. And the increase in performance of the app is quite noticeable. I think it's fair to say it runs at near native speed.

Configured with service workers to run offline first the web app only checks the server to see if any updates have been issued and if not it never sends any data over the internet.

It's very easy to provide the user an option to sync their local CouchDB with one in the Cloud, and they can turn that option on and off. When it's on they can access their data with any device and "Live Sync" the data between the Cloud CouchDB and their Desktop CouchDB.

Now, it's beyond my skills to develop it but it seems to me that a sandboxed runtime engine for web apps on mobile devices would be a good thing for us all. Of course, I don't think Apple and Google think so, but they do most definitely depend on indie developers to entice people to use their devices.
Probably because the app was tested on a prerelease version of macOS and you're digging into the developer for having poor EQ.
Houston homicide rate: 12.1 murders per 100,000 population

Nigeria homicide rate: 4.5 murders per 100,000 population

Siena homicide rate: < 0.5 murders per 100,000 population

It all depends on how you spend that money...
> the reason I choose Apple is because their product and software ecosystem the one I love the most out of any big player ... we’d probably agree on 90% of your pain with Apple

Sounds like you’re a bit conflicted. I also chose an Apple phone and tablet because they seemed like the best choice available at the time, despite being part of the Apple “ecosystem” which prevents these devices from interoperating with my non-Apple devices.
A thread on the disaster that is Star Citizen
The Trillion Dollar Question Facing Every Major American City
Given the state of computer vision, and how easy I thought it was to detect and read a speed limit sign, at least in "ideal" conditions, that I was surprised when I first got a Tesla with their new (at the time) "HW2" hardware, that it was NOT reading speed limit signs. This is back in late 2016.
I just love it. Well done.

Have you considered a weight sensor or maybe sound sensor to determine when to close again? I assume it’s on a timer at the moment.
I hate the overuse of acronyms (IHTOOA). One way to get back is just to start making up your own -- throw a few random TLA's out at your next meeting. It's fun.

Also, I would like to push for an anti-acronym day. A full day where you have to use full and complete terminology. Ironic thing is, you don't add that many syllables when you say "Proof of Concept" vs POC and similar such absurd overused abbreviations.
What is your opinion of open source solutions like ArduPilot?
Minimal WebView-Based Desktop Apps: Electron vs. Chromely vs. Edge vs. IE11
I'm curious, what startup that is? FWIW, I think there is a large opportunity here (make sync+collab easy => ecosystem of products that tightly sync) that can be disruptive to many SaaS businesses.

I'm keeping an eye on Croquet: https://www.croquet.io
I am in fact a small farmer and I have and use a compact utility tractor. Sometimes I use it for an hour or two. Sometimes I’m on it all day long.

I lift full 500 lb round bales with my Ford 1320. Very carefully.
To me the benefit of Rust is less safety, than better abstractions and modularity.
Linux has been growing in complexity without much of a breaking point, and the discipline and separation of concerns high level languages could help with is a huge long-term benefit.

(For example, say we could one day make a bunch of basic Linux drivers somewhat kernel agnostic? That would be amazing.)

Now, ATS is I hear a fine language, but I think the ability to write good, and especially abstract, ATS is sadly too far outside of most kernel dev's skill set. Even among PL researchers, there is a tendency to write monolithic Coq---to wit, is there a Hackage or crates.io for Coq?---because abstraction are hard and the academic paper economy doesn't really reward it.

Rust is just easy enough, and with enough crates.io momentum, that I hope the relative cost of reusable vs unreusable code will be less.

And finally, it takes a lot of political will to introduce a new language in any existing project, let alone one as big and storied as Linux. Like it or not, but general popularity of the language absolutely does help with that.
The licensing incompatibility is not arising from the CDDL licence, but the GPL. You can combine the CDDL with pretty much anything.

As a result, it would be extraordinarily difficult for Oracle to sue since it would not be the CDDL licence terms which were infringed.
SISR makes every cam a super-resolution device
href="javascript:;" is also bad. It doesn't work if you try to open it in a new tab. Just use a real url!
Setting up advanced registration forms with FusionAuth
Actually, what killed both is market size.

Internet boom === small simple apps where emphasis is either on looking good or being very responsive.

That meant that vast majority of developers where not in a market for rich GUI stuff, but for better CSS and smaller size.

OTOH desktop never rewarded simple apps. Distribution and marketability asked for more features exposed via GUI, thus most developers where OK with bigger in scope GUI stuff.

As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now. Include polyfills, css defaults reset, do transpiling into less features and you are good to go.

OTOH, web underwent multiple groundbreaking shifts in computational models. This is why complex but somewhat encapsulized/localized Angular/Ember won over spaghetti inducing predecessors and why truly encapsulated/localized Reacts eats old Anguler for breakfast.

One last point would be about crazy stuff in programming languages / programming paradigms that was already available in 60's and 70's at least as a statements of need.
Those made for very stable platform on which GUI ecosystems could be build.
Relative instability of JS with generational changes can explain why it gets a new ecosystem every few years.
> crisis relocation (which, in an earlier form, was a major motivation for the Eisenhower freeway system, to the extent that it's probably fair to say that it was the main motivation with materiel movement as a second)

I've heard that before, but the DOT claims evacuation was a minor factor. From https://www.fhwa.dot.gov/interstate/interstatemyths.cfm#ques...

President Eisenhower supported the Interstate System because he wanted a way of evacuating cities if the United States was attacked by an atomic bomb.

President Eisenhower’s support was based largely on civilian needs—support for economic development, improved highway safety, and congestion relief, as well as reduction of motor vehicle-related lawsuits. He understood the military value of the Interstate System, as well as its use in evacuations, but they were only part of the reason for his support.

Defense was the primary reason for the Interstate System.

The primary justifications for the Interstate System were civilian in nature. In the midst of the Cold War, the Department of Defense supported the Interstate System and Congress added the words “and Defense” to its official name in 1956 (“National System of Interstate and Defense Highways”). However, the program was so popular for its civilian benefits that the legislation would have passed even if defense had not been a factor.
> So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM)

The answer to this question appears to be: no.

Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in things like the Linux kernel as well as the Windows codebase). C++ hasn't seemed to have changed that, either.

Remember, Rust IS Mozilla's answer to this question.

> without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust".

The requirement to do that is pointing out the that kernel API is poor and is too intimately tied to the build chain. We have seen this before--when Linux got ported to Alpha, for example.

The point is to fix the API so that more languages than just Rust can be used.

I suspect that more "system programming" languages may appear once Rust does the difficult groundwork of breaking this kind of intimate toolchain dependence. As things currently stand, why develop a system programming language given that no one will ever use it?
Reading through your various replies to comments, it seems your argument boils down to the FFI issue, and I find that a little bizarre. Sure, ATS can inline library calls due to the lack of an FFI, and maybe it has a cleaner interface to those libraries, but now you've introduced a completely different set of problems: now you have to tell the compiler how to prove your code.

In my experience, learning the fundamental concepts behind theorem proving is a lot harder of a problem than writing an FFI interface to a library. In fact, that problem is so easily solved that there are tools that do 99% of the work for you.

And sure, maybe rust will never be able to inline C code, but inlining function calls is such a trivially small performance gap that most applications would never know the difference.

I'm not convinced that there are better alternatives for contributing to or incrementally rewriting an existing code base. FFI is for most purposes a trivial impediment compared to the alternatives.
Are you in the UK? Such terms are common in tech here in the UK.

I also had a job offered with pretty much identical terms. I planned to disclose and negotiate this clause after negotiating the salary (they offered less than I used to make) but they walked off in a huff when I pushed back against the offer. I did not regret it as I have IP that I have been developing for years and I hope to spin into a company in a couple of years.
Even if we are discussing a pair of points on adjacent polygons? Wouldn't the shortest path go across the one and only edge the polygons have in common?

I'm looking at the diagrams on that Wikipedia page. It looks as if we require the path to visit certain polygons, then it is in fact the shorted path which visits those polygons.

In both solutions, the path traced along the unfolded jacket of the box is in a straight line, obeying the principle we have been discussing.

I don't think that what we are looking at there are simply two different "different unfoldings" of a polyhedron; they are different choices about which configuration of edges to separate in forming what is evidently called the net of the polyhedron:

https://en.wikipedia.org/wiki/Net_(polyhedron)

They are different "nettings", if you will. We can crack a polygon into more than one net, but a given net has just one unfolding.

(If we choose a particular net of a polyhedron, can that have more than one shortest path between some two points?)
You're supposed to decommission them once you have replacement power.