I suppose you're right: an email with password could be sent during the registration process. As for using encryption for password files that isn't one way, I consider that to be bad practice. The decryption key will have to be kept on the live system, where it can be stolen just like the password file, or the serice could even be exploited to give up the key or decrypt a password. Better if that wholly unneccessary operation is mathematically (nearly) impossible.

Be careful: even if this means that they will only require data to be handed over if the requesting agency has a signed warrant, the phrase "no safe space" can only mean that private crypto is outlawed, Encrypted email, peer to peer encrypted chat and even encrypted messages in public channels are closed off to everyone except the key holders, closed even to ISPs, the chat service provider or the app builders. In other words, they are safe spaces.

Requiring a warrant means that the government should have access to our data on reasonable grounds, but only if such data is accessible. I am all for that. But the phrase "no safe space" is a telling one: it means ensuring that our data is accessible in every case, and that goes a whole lot further. If the government has access, then our ISP or the service provider has it, and that means our data is not safe.

If passwords are sent in the clear, they are kept in the clear (unless they are one-time randomly generated passwords). And if you check with black hats, you will note that they steal password files all the time. In most cases they'll end up with password hashes, which means they can spend some time and computing power to throw a dictionary at the file and see if any semi-obvious passwords come out. But if passwords are stored in the clear, they end up with everything, no matter how strong your password. And if you use that same password on multiple sites, you'll be in even more trouble.

This. We got 7 billion people - probably closer to 10 before it peaks, and as a minimum I should have one IP address at home, at work and for my cell phone. So 3*10 billion is 30 billion, IPv4 can offer 4 billion. And that's not counting every other odd thing I might want, like remote-controlled alarm/heating/whatever at my cabin or my car, servers of various kind and maybe IoT will become good for something.

Of course they probably could have just done it much, much simpler by making a dotted quad a dotted quint:

1.2.3.4.5

For compatibility each host under 1.2.3.4.x is granted 256 ports IPv4 ports mapped from x*256 to (x+1)*256-1 to a designated "IPv4 compatibility ports" like say the last ports from 65279 to 65535. So 1.2.3.4.1 can either be fully addressed by quint-capable equipment or 1.2.3.4:256-511 that'll be mapped to 1.2.3.4.1:65279-65535. And 1.2.3.4.2 will have 1.2.3.4:512-767 mapped to 1.2.3.4.2:65279-65535 and so on. You could use the same technique to provide a virtual IPv4 interface for legacy software, it thinks it is listening to 1.2.3.4:256 but it's really listening at 1.2.3.4.1:65279 - and any application it tells to connect to 1.2.3.4:256 would work.

That would have led to a gradual 256-times expansion of the address space without any hard switch-offs. But instead they decided to solve everything and now 19 years after the IPv6 standard we're still only barely in motion.

Bait and charge.

Exactly. They are no one's to share but the owner of the access point, and when you give your house wifi password to a guest, most of them do understand that it's not ok to give that password to others. That changes when sharing passwords becomes a built-in or even automatic feature; if there's a button to share, it'll give the impression that it is safe and acceptable to do so.

They did no such thing. The Windows 10 upgrade thingy makes it crystal clear, several times, that the upgrade is optional. You can decline by not "reserving your copy", and even if you accept, you still get the option to not download and install the upgrade when it's there.

With that said, I agree that sharing WiFi passwords with your contacts is a monumentally stupid idea.

The very page you link to says:

What's ICU?

Not sure exactly how much Qt functionality you'd lose, but it's an optional dependency.

Or maybe it's okay if systemd fucks up all the servers running RHEL 7. After all, nothing important runs on that. So let's check, is Red Hat Inc. tanking and considering backtracking? Hell no, they're growing strong both in revenue and profits in the year that's passed since. So if a $14 billion dollar company can make systemd work for them, it probably can't be that bad. Or if it's bad, well then rip out the bad parts like write a non-binary log because how hard could it be to take the binary messages, printf and log the text in addition to/instead of a blob? Sometimes it sounds like the only two options is to drink the kool-aid or nuke it from orbit.

There really is no issue to be downplayed. It's an image recognition algorithm, and it's going to make mistakes. Some hilarious, some embarrasing. But none of it intentional. Unfortunately there will always be people who will see malice in every mistake, and take the slightest affront to whine loudly. If the affront happens to involve any minority, you have a "winner" on your hands in terms of righteous indignation.

An apology is in order, nothing more. And only to the misidentified people, not to the black community at large, Seriously, if the system had identified a white couple as polar bears or Klan members, people would have just laughed.

Not sure if you're stoned or trolling or dropped out of a time vortex from the 90s, but

1) GUI installers have been the norm for desktop oriented distros for years, mostly through live CDs.
2) For most of Linux history there's been zero credible competitors to X
3) Wayland is mainly driven by ex-X developers
4) Wayland will still need drivers to have accelerated graphics

5) Neither application developers nor users usually see X, you write against for example Qt and the toolkit takes care of talking to X. They might hate X, but they hide its quirks pretty well.

I think those wanna-be generals aren't really the community, but those who want to exploit the community to achieve their pet goals. To steal an expression from 4chan: The FOSS community is not your personal army. The opposite is less intuitive, but it also means the community isn't going to stand still just because your pet needs have been met while many others feel theirs haven't. For example I haven't heard much shit about PulseAudio in recent years, though initially it was rather crappy but it did add features that didn't exist before. Maybe in ten years time we'll feel the same about systemd.

No.

Careful, the same would imply that someone who can manage projects, manpower and deadlines can manage pointers and complex sets of data safely. The most fundamental difference is that working with people is that your subordinates have a brain and will let you know when something is obviously wrong, non-nonsensical or impossible. I don't mean they're geniuses but the computer isn't even toilet trained and will poop all over the floor if it can't find the bathroom. It'll go in an infinite loop or write full the disk or flood the network or trash the database with total obliviousness.

Half my job is figuring out every conceivable way the system can crap out, take bad input, return junk or be exploited because the system won't deal with any situation on its own. Project management is a lot more about resolving the daily issues your team is struggling with right now, not chasing corner cases that might one day happen. And the software solution is often just throwing some kind of error, if you're aware you've almost trivially dealt with it.

Management problems are typically "soft issues" that doesn't have definitive causes or solutions. Like today we talked about a new reporting solution that is behind schedule and how the estimates were set and causes they're off, consequences, remaining uncertainty, mitigation strategies, if it's possible to free up existing resources or add resources without running into the mythical man-month and how we plan to deal with our needs just not today but going forward. You're not chasing a bug in code that you can patch and declare fixed. It's a constant re-balancing of competing priorities.

Sure, as long as you use some GPL code the requirements apply to the work as a whole. But if you write part A using the GPL license, I can write part B using the BSD license. The GPL license is okay with A+B and if someone wants to use part B in a non-GPL project or replace part A with differently licensed code they can. The point was he doesn't have to use the GPL unless he wants to. He can use a far more permissive "I don't care, use it wherever you want" license for his bits.