That bug history was one of the more painful things I've read recently.

User: I want a thing!
Damon: Have a thing!
devTeam: Two years of bickering and bikeshedding
Damon: FFS. Peace, y'all.
devTeam: 15 years of dithering and hand-wringing
SomeoneElse: Okay, enough waiting. Here's a competing solution that doesn't need upstream buy-in
devTeam: 4 years of drumroll...
devTeam: HAVE A THING! (are you still alive, User?)

FreeBSD recently went through this with getting a recent build of .net ported over. A college student got Google Summer of Code to do the port, actually got it working and got some level of assurance from the .net team that a clean patch would get some level of platform support. Then one of the FreeBSD ports reviewers crapped all over him not using the ports system completely properly. In the time it took to make those folks happy, Microsoft released a new version, making the patches stale. Since FreeBSD didn't get supported in time, they were left in the dust.

I've worked with enough cowboy coders to appreciate needing to meet a certain standard before check-in, but it's always tragic to watch someone do 90+% of the work only to be shut down over relatively insignificant stuff. It's the end-user who loses out. FreeBSD users still don't have an up-to-date .net for hosting services (apart from Mono, which is always chasing a moving target), but at least Thunderbird users finally got PGP. Yay?

My point is that everything a PowerMac G5 can do, idling at 500 watts, my pocket computer can do at less than a watt.

The difference in power draw isn't so dramatic. A quad-core G5 fully tricked-out would pull about 455W at peak, and closer to 100W at idle, about the same as a modern workstation. To meet it in CPU power, you'd need two Raspberry Pi 4 systems, which would be at 30W at peak. So, while a very significant 15x power draw, not quite hundreds of times.

There is no point, unless there IS something a PowerMac G5 can do that a modern computer can't.

There is probably no point in you getting a G5 to run MorphOS. You're not their target audience. Computationally, there's nothing a G5 can do that an ARMv8 or modern x86 can't do faster with less power consumption.

But for a certain sort of person who values computers that had usefully-extensible firmware (you can customize a G5's firmware in NVRAM, without a compiler); didn't have the hardware-level security concerns of RowHammer, management engines, and speculative read abuses; and didn't all* run the same CPU family, hacking on older systems like PowerMacs, SPARCstations, and Alphas will always hold some appeal, and there's great satisfaction in doing modern workload on those systems with svelte software.

* Yes, I know you can allegedly get ARM-based workstations; I've got a nice 6-core ODROID box, but just try to plug real disks or an additional network interface or a more mainstream GPU into it. Real ARM workstations are still eye-wateringly expensive.

A gallon jug still holds a gallon of material a decade later.

Those old Apple computers do everything that they did when they shipped. Most of what the typical person does with computers (excepting gaming, the more advanced/bandwidth-efficient video CODECs, etc.) isn't that much more intensive than it was when these computers were new. However, the software we use to do that work gets progressively more crufty and slow as it acquires more complexity in the name of features.

Is this a mainstream project? No, of course not. It wasn't meant to be. But the companies who make money selling new hardware didn't obsolete the old stuff purely out of benevolence, and sometimes it's refreshing to embrace that.

They could hardly have named their project something more resistant to a search-engine query.

Is it great? Is it crap? Will it trip the stupid "Knox" counter on my Samsung handset? Let's try to find out!

Searching for "/e/" "knox"... I'm sure Harvey and David were were nice blokes, but that's hardly relevant.

Okay, about about "samsung" "e os"... I don't read Portuguese, but I'm pretty sure none of this applies.

What about "Android" "e os" "knox"? That's no good, either.

Programmers (and I speak as one) should approximately never be allowed to name anything outside of API entry points. It's just not a skill we seem to have. See also: Libreoffce, Wodim, Drizzle, Drupal, and many others

do the background checks. Every. Single. Time. It protects the person giving the gun to the other person, it might protect the other person

It only protects the people involved from consequences that would not exist outside of the law mandating the background checks! That's not a net benefit.

Back to the time a friend of mine showed up at my house with a trunk full of hunting rifles because she had someone staying over who shouldn't have been around them. What do you do for background checks at 10:30pm? Do we break the law or do we leave the weapons within the dangerous person's reach? Or do we tell that person that he's just going to have to sleep somewhere else because some paperwork needs filling-out first?

At no point in that situation would some paperwork have made anyone safer, but mandating that it be present would make things more perilous for everyone in the situation who hadn't hurt anyone.

It protects you from being liable when you give deadly weapons to someone you think you know and can trust but who actually has a restraining order on them due to a domestic assault and threats of violence.

If I had any question, I wouldn't give that person access to a weapon. Do think gun owners trade them with each other like baseball cards? They're dangerous and expensive tools!

Why is this so hard for you to understand?

Criminals break laws, by definition, which is why fewer than a third of guns owned by criminals were purchased above-board or received by a private-party transfer. Making compliance with the law harder on people who intend to do right by it creates opportunities for accidental criminality (the house-sitter who knows where the safe key is, for example). Rather than making people safer, this makes the laws less effective, doing little to deter intentional criminality.

If you want to have deadly weapons, you need to be responsible for them.

100% agree.

I don't care if that's fucking hard. Tough shit

I'm not complaining that it's hard. I'm asserting that the additional work does not make anything safer. Having to fill out a transfer form every time I trade rifles with someone at the range makes no one safer. Criminal liability for holding onto a weapon owned by my brother when we can't get to an FFL for a day or two does not make us safer.

If you tell me that stacking stones in my garage will keep the neighbor's house from burning down, I'm not a pyromaniac for not wanting to participate: just skeptical.

People die every day because we don't insist that weapon owners be responsible. Why are you OK with that?

Logically inconsistent. The only person responsible in a shooting is the person pulling the trigger. None of the weapons I own has been used to harm another person because I am a responsible weapon owner. I do not give, lend, take, or borrow weapons with people I don't know well enough to vouch for in court. Mine are locked up, ammunition safely stowed elsewhere.

That is what responsibility looks like. States like New York, California, and Illinois--all of which require background checks for private transfers, all of which have really stringent criteria for what constitutes as "transfer" and all of which have terrifying levels of gun crime--illustrate what responsibility is not.

Why are you against taking personal responsibility?

I'm against security theater and its red tape.

The big problem with requiring background checks on private-party transfers is that a great many things inadvertently classify as "transferring" a firearm.

Leaving your weapon in someone else's vehicle is a transfer in some jurisdictions. Letting someone else test-fire a few rounds as a transfer in some jurisdictions. Letting someone house-sit for you can be a transfer of the weapons in that house if they're reasonably accessible (ie: the safe key is in a location known to the person house-sitting).

Let's say I have some number of weapons at home, and I have someone coming over to visit for a few days who should be kept away from weapons (history of psychotic incidents, alcohol or drug abuse, just got out of jail, etc.). As it stands right now, I can drive those weapons to a trusted friend's house and leave them in his care. Right now, this does not require a background check. In many states that require background checks for private transfers, my friend would need to pass a background check to take temporary possession of the weapons, and I would need to pass a background check in order to retrieve my own weapons!

So what do I do? The responsible thing would be to pay for two background checks and the filing paperwork. This is a tax on doing the right thing; that is, I would be incentivized to keep the weapons within reach of a dangerous person.

I have been that trusted friend before. I'd do it again, and I'd do it without filing paperwork because the paperwork makes no one safer.

This is not a law that makes the world safer. It is a law that makes the world more burdensome.

Instead, the 51 CEOs would like one law that governs all user privacy and data protection across the US, which would simplify product design, compliance, and data management.

...which will, completely coincidentally, demand a level of red tape infeasible for small start-ups to meet. Small startups who might otherwise threaten the marketshare of these 51 giants by offering a compelling new "killer app" to users.

Fixing the privacy policy is relatively simple (but not easy):

1. Compel corporations to publish their their data-sharing policies, if they have such policies, in colloquial English, either instead of or in addition to the dialect of technical English used in contract law. If the colloquial version is misleading (relative to the legal version) in a way found to be intentional, that should be actionable. Not having a policy and then sharing data is, in essence a breach.
2. Make corporations strictly liable for breaches, and make their officers liable in the case when it was intentional. None of this nonsense where Equifax leaks the data on half of everyone and gets to offer free credit monitoring plus a nominal fine to cover their gross negligence.

They can either fix their nonsense, pay through the nose, or pay for insurance (which will shortly demand their nonsense be fixed). Small companies can still innovate, upon the potential pain of being sued out of existence if they screw up.

clicks TFA

Ilya Suzdalnitski. Senior full-stack engineer. Guides teams to building reliable software. JS/Node/React.

Clean up your own house, first. The current impending disaster is that people are building "full stacks" in a programming language where you can add NaN to NaN, divide that be zero, compare the result to undefined, and not get a single exception along the way--a language with coercion rules so irreparably wrong-headed that it had to add a coercionless equality operator!

You don't need OOP to have promisculously-shared mutable objects. You don't need OOP to have an abstraction mess. You don't need OOP to have conflated concerns and unmaintanable spaghetti.

You get all those things by not realizing that API design is a totally separate skill from implementation--almost to the same degree that being able to write coherent documentation is a separate skill. Instead of recognizing that separation, industry conflated them, and OOP was the crutch used to give people without API design skills a cargo-cult religion for building things.

Used well, OOP can express relationship between complex concepts as easily as FP models relationships between types. Used poorly, you get the same garbage you get from using anything poorly. It's just that OOP garbage tends to be more verbose.

Any information that you provide to anyone, any entity, government, web site, company is no longer yours only. And no laws or regulations can return it.

Obviously you've never once in your life worked a job that requires HIPPA or PCI compliance.

Requirements describe an ideal, but the cannot redefine reality. When we say "information wants to be free," we don't mean that it wants to be free like refugees want to be free. We mean that it wants to be free like nitrogen wants to be free. Put enough nitrogen in one spot, and it will go out of everyone's way to get free; interesting data will find a way to do the same when it passes through too many hands, and that requisite number of hands decreases as the concentration of data increases.

Much like the only way to secure a computer is to turn its disk to slag and drown its circuits in seawater, the only way to keep data private is to not share it.

There should be consequences for people who abuse the data entrusted to them, but the threat of those consequences is not an guarantee that abuse is impossible.

Yep. I run it and love it on my Linux systems at home. At work, though, I have to deal with systemd all day, so I run Debian unstable.

The Devuan folks have an uphill battle ahead of them, though. More and more software is getting sucked into the systemd ecosystem because of its heavy-handed policy and vast market share. They might find themselves having to support forks of fairly complex tools just to keep that dependency away.

By the same token, systemd just might make a whole lot of Linux software Unix-incompatible.

Yet I can't help wondering how much of it is really just people who resist change because they don't want to learn something new.

Probably a good chunk.

That said, init and upstart solved problems in a fairly small domain: starting daemons in dependency order. SMF, launchd, and a few others did the same thing. They sucked to learn, but they gave us parallel startup, services that could start in response to events (logins, socket connects, etc.) and that was worth some relearning.

Things that systemd has embraced into its scope that SMD and launchd did not include:

• System logs
• Control groups
• Resource accounting
• User session management
• Power management (suspend/resume)
• Time synchronization
• Temp file cleanup
• Name resolution
• Hostname setting
• Privilege escalation
• Disk, Volume, and Metadevice discovery

Thanks to RedHat's backing, the systemd developers have a bully pulpit to force policy on Linux users everywhere. Like when nohup stopped working by default. The usual rationale from Poettering and company are that things are "broken" or "nobody needs that."

Right now, on my Debian box, in ~root/ is a script called thanks-systemd.sh. It mostly boils down to: cd /dev ; for i in dm-? ; do ln -s ../$i mapper/$(cat /sys/devices/virtual/block/${i}/dm/name); done

Because for about two weeks my system stopped autobooting due to some churn between LVM2 and systemd. LVM2's worked nigh-flawlessly for 20 years, and its semantics haven't changed.

It's one thing to change a clunky misfeature (init scripts) in some jarring way to make them better. It's quite another to take over most aspects of systems management, do them differently "just because," and break random things because of scope creep.

"enforcing free speech" isn't a thing.

Perhaps not, per se. However, Section 230 of the Communications Decency Act provides a "safe harbor" against people who run web sites from being treated as the "publisher or speaker of any information provided by another."

This sort of provision is directly at odds with the notion of editorial control. Being able to say "we didn't say that" is effectively a lie when spoken by someone who gets to control exactly what got said.

There's lots of grey area and middle ground, but there needs to be some sort of litmus test for whether or not these platforms' "Community Standards" are valid in the context of Section 230. On one hand, no one wants to put in all the work in hosting a platform just to have users fill it with filth. On the other, the standards need consistent application so that, for example, a post of "Kill all x" is equally offending for all demographic values of x; or, that those Community Standards aren't a mere rephrasing of some group's political platform.

I'm all for site owners to say whatever they want and face whatever consequences come their way. I'm all for platform providers not being held liable for the things that other people say using those platforms. I'm not for platform providers getting that (additional) legal protection while effectively acting as a publisher/gatekeeper in an increasingly-consolidating Web.

Was that the gut-wrenching sound of a paradigm shifting without a clutch?

Make a "fat macbook" with USB-A, 17 inch screen and optical drive and long battery life and it will sell like hot cakes.

Yep, that's the Mac I wanted--and the Mac I upgraded to every two-to-three years starting with the first 17" PowerBook G4.

I'm told we're a niche market. We're too picky and too expensive to cater-to relative to the masses of people who just want a shiny Facebook/YouTube machine. I was told that a 15-inch screen is big enough, that I really would never want to upgrade memory or storage, and then I was told to be patient while iOS got all the attention from Apple's OS engineers.

So I waited. My most recent Mac is 8 years old. The new OS X won't run on it, and I can't even get a 15 "Pro" MacBook with an "escape" key. I didn't really want to run Vim, anyway, I guess.

I've stopped waiting, and now I carry a ThinkPad. It's big, it's ugly, it's fast, the battery lasts all day, and I can swap out parts as I need. Shame about losing my investment in software for OS X, but Apple have firmly and repeatedly told our type that we're not welcome at their party anymore.

If 22% of TV purchasers defaulted, leaving Wells Fargo to pay the bill, you bet your ass Wells Fargo would stop paying for TVs.

If that were what the article said, it'd imply that Wells Fargo should stop issuing lines of credit in excess of what people can repay. Whether the money was spent on Dogecoin or Home Shopping Network kitch, it's spent. The limit is there precisely so that the consumer doesn't spend more than he can repay (even if it is a long way down the road to paying it off).

Instead, what the study referenced in the article actually said was that 22% of those who purchased cryptocurrency on credit are still carrying a balance. Only 11% of those people carrying a balance said they wouldn't even sell their stake in crypto to pay the balance, which is greater (by 50%) than the average rate of default, but that's only considering this self-selected group of people willing to take extraordinary financial risk (and, we can presume, are not a typical cross-section of cardholders).

So, roughly the same number of people are being irresponsible with money as usual, but because they're being irresponsible in a new and different way, it's time to sound the alarm!