estebank

Most of the time is spent figuring what the right thing to do is, not writing the implementation. Sometimes the process of writing the implementation surfaces new considerations about what the right thing is, but still, producing text to feed to a compiler is not the bulk of the work of a software engineer. It is to unearth requirements and turn them into repeatable software.

> The UFO nut community is being weaponized for political leverage

Always has been, at least since 1947.

Please don't, at least not mimicking the "edgy 13 year old thinks it comes across as cool" tone.

If the toolchain crashed while compiling, please file a ticket! That shouldn't happen ever and if it does it is indicative of a big problem that needs fixing.

Firefox explicitly opts out of stability guarantees by using nightly features on a stable compiler in an unsupported manner, not dissimilar to using an unstable GNU extension in C. But good example of the caveat that if you're not using stable, then yes, you have no stability guarantees.

I think the divide is apps vs libraries: a library that requires their dependants to set an environment variable opting out of stability guarantees is unlikely to gain adoption, but applications that do so are more common, like Firefox.

Under that rubric, no language is memory safe.

This attitude doesn't even work in carpentry, depending on the timeframe you look at, tools have changed over time. You can still use a hand saw, where a table saw would be just as suitable, or have a SawStop(tm) and reduce the likelihood of losing a finger.

Do you recall which libraries? Use of nightly fell of a cliff after 2018. Looking at the bottom of https://lib.rs/stats#rustc-usage, ~8% of all crates.io requests came from a nightly newer than that corresponding to 1.86. That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed. The prevalence of nightly is also niche specific. If you're in embedded it is likely you need to use some nightly-only features that haven't been stabilized, but if you have an OS chances are that you don't.

In many countries the state owned the phone company.

Code in all languages bitrots. Even if your dependencies are "done", the language is unchanging, the toolchain mature, a vendor can introduce a new platform and all of a sudden your code won't compile anymore, because IBM introduced a new RISC server platform, or macOS changed the definition of time_t, or Windows blocked direct win32.DLL access (I know, a stretch), that your older libraries didn't know about.

Even if a crate is yanked, if you have the version in a lock file it will still download and build. (This was done precisely after seeing the left-pad incident.)

Do you remember more specifics? I've seen four cases:

- a project with no Cargo.lock, where there have been breaking changes in a dependency that wasn't specific enough in Cargo.toml; fixing this requires some finessing of dependencies but is possible to get the project building without any code changes

- a project with proper dependency tree specified, but where a std change cause inference to break specific older versions of a crate in your tree (time 0.35 comes to mind); this requires similar changes to the above

- a project relies on UB on stable code that should always have been disallowed and since fixed; this is tricky, on a dependency, an updated version will likely exist, on your own project you'd have to either change your code or use the older toolchain, knowing that the code might not be doing what you want it to do (this happened a handful of times pre 1.20)

- an older project, with the proper dependency versions specified, being built on a newer platform; I saw this with someone trying to build a project untouched since 2018 on an ARM Mac: the toolchain for it didn't exist back then, and the macOS specific lib they were using didn't have any knowledge either. Newer versions of the library do, of course, but that required updating a set of libs that would be compatible too.

All of these cases are quite rare. You could encounter all of them at the same time, and that would be annoying, enough to have someone doing it for fun say "fuck it" and drop it. You can also get hit by a lightning.

But between Cargo.lock which should allow your project to build on newer toolchains, and access to all prior toolchains, your project should continue to build forever on the same platform.

Can you point at any piece of code from 5 years ago that doesn't work today?

Your customers should be proper Spaniards and be watching the match, hence not noticing the downtime! /s

On the one hand, I would tend to agree that making things painful enough might force people to stop ignoring and improve things. On the other, after seeing waves hands at everything since 2016 makes me very skeptical of accelerationism: sometimes things just get worse and worse, there's no bottom to bounce from. Or maybe we just never really hit rock bottom?

Delaying the run of clippy until CI would be annoying, because then you'd get a build failure for something that was preventable and could have been quickly addresses during development before pushing. Just feels like a pebble in your shoe.

>>> I don't care, I run Graphene, and my phone is definitely mine.

I really don't see an implied "and you can too".

> For executable applications it makes sense to not want GPL only when you want to extract parts of them and insert them into other programs.

It is very common for applications written in Rust to be split in multiple reusable crates. Looking at the main crate, that is the case here too: https://crates.io/crates/coreutils/0.8.0/dependencies

This allows for the learnings of uutils (and by extension GNU coreutils) to be able to be leveraged by any other project that needs the same functionality. I noticed on a quick scan of the dependents on uucore that other projects (like nushell) do so.

I've found that RCS works ok-ish on the Owner user, but doesn't work at all on any other (it appears as an empty message). Moving to the Owner account you can tap to redownload the message and then it appears correctly in all accounts. It's a mess that makes daily driving a secondary account not worth it

I haven't found the need for deeper integration with my laptop beyond what KDE connect is capable of, and my Pixel has a high enough resolution that I can't notice pixels :)

This will not help you in your country, but in places where it is sold, you can buy used one of the prior generation phones, which are also supported.

The interaction of secondary users with RCS is borked to all hell. It just plain doesn't work.

Firefox + stock keyboard stopped properly working three days ago, it's back to normal now. No idea what that was about. Restarting was the only way I found to get things working again during that period.

While on the stock Android keyboard, it is clear that the Google one is much better at correcting my taps than the stock one. My typo count has gone up significantly.

Every several weeks the mobile connectivity stops working and nothing short of a restart will get it working again. This might be a bad interaction of the very weird way Google Fi works with a secondary user account.

I've encountered one case of the phone shutting itself off to install an update overnight and not turning on, making me miss my morning alarm.

In the US, there's no way to side step the lack of tap to pay.

Getting apps to work with Android Auto requires some finessing.

These are the things I've encountered in the last 2 months of using Graphene.

Aside from all of that, I really like everything else about the OS. As it stands, it does lacks polish when straying outside of the common path. Not using a secondary account, nor Google Fi on an eSIM, and using the stock browser would likely improve my experience significantly.

I haven't encountered an app that wouldn't work yet (but have installed play services as I do want to use Android Auto).

I would still recommend Grapheme for normal-ish users, as long as you don't go "paranoid mode" with secondary accounts and skipping play services or don't want to use the phone for tons of things beyond phone calls and web browsing. The base experience is that much calmer than stock Android on Pixel.

I use GrapheneOS too. Most of the time it works great, with some weird bugs around group messages and needing to restart every now and then to get to a fully functional state between the browser and keyboard properly working with each other and the network connectivity going away. I do enjoy full control on network connectivity and notifications.

But beyond whether the OS is good or not, "fuck you, I've got mine" is not only sad as a position in general, it is also a bad tactical choice, because over long enough timeframes you can't assure that you can keep yours if others are deprived.

When was the last time you checked South Korean law?

Is anyone disputing that?

What people are arguing against is that making having a passport mandatory to participate in society is an unreasonable burden, under the current structures. If you wanted to mail a passport to every American in the mail, at no cost, no questions asked, that would be a very different proposition to what is being discussed.

Surprising to see that the cost of a passport is lower than the identity card.

https://poliisi.fi/en/identity-card

It depends on what problem and how you're "solving" it.

> It took me ~30 seconds to find a document to prove my current residency. Trivial for a homeless person as well. Zero excuse.

Is this satire?

The additional 165 dollars to get a passport for the first time is quite steep for a document that seems to become more and more mandatory. Papier, bitte.

Countries with national IDs charge you to replace one if it gets lost, and it usually costs less than 10 USD.