> While we did initially start out on a single computer in 1987, the
> SDF is now a network of 8 64bit enterprise class servers running
> NetBSD realising a combined processing power of over 21.1 GFLOPS!
Which piqued my interest about how that compares to today's computers. nVidia's venerable 1080Ti from 2017 measures about 11300 GFLOPS, or 11.3 teraFLOPS. About a fifty times increase.
Been running Aeon, the Gnome version of Kalpa, on my personal laptop for about six months now. I came from Tumbleweed so the learning curve wasn't steep. Overall the experience has been good!
The one major issue I had from the start was non-free Bluetooth codecs like AptX. That required me to taint the base image and add a non-official repo. It was messy but that was mostly down to it being a learning process, if I had to do it again I could probably do it with a single run of `transactional-update shell`.
The installer is super minimal and surprisingly user-friendly. One thing I remember is that there was zero partitioning choice: just use the full disk for encrypted btrfs and you get no swap (but zram swap is on by default). If you use OpenSUSE with secure boot enabled (as intended) then hibernate is prevented by `kernel_lockdown` anyway.
Snapper by default is nice, but you also get that with Tumbleweed. I ran into no applications that I couldn't get from Flatpaks or export from a distrobox, the latter being mostly for obscure stuff I need to compile myself. And my main toolbox hosts my Emacs environment that I spend most of my time in besides Firefox.
It's hard to recommend a MicroOS desktop over Tumbleweed, the latter being a great all-purpose distro as it is. But I'm hoping the benefits of forcing this "rootless" paradigm on myself will appear when it's time to move to a new machine. Just copy over my home directory and distroboxes and I'm golden, I could even switch to ARM without hesitation.
The distroboxes help with migrating because if I want to compile a newer version of that obscure program from earlier, I don't have to hunt down all the arcane requirements again. They're all still there waiting for me, in a Fedora/Ubuntu/Arch/whatever distrobox, depending on what works best for that program. At least that's the theory.
I did some manual partitioning when installing Kalpa: I added a Swap partition whose capacity I set equal to RAM + 2GB, which got hibernate working.
I think Hibernate is strictly better than Sleep: Why should a computer still use power when it isn't doing anything? And if you could get a desktop to recover its state before a full reboot without using Hibernate, then why would you need Sleep anyway?
Yeah I read further down in the comments that Aeon and Kalpa have actually diverged quite a bit, the installer might be one of those divergences. How are you liking Kalpa?
The main benefit of sleeping to RAM is of course the resume speed, which makes it more suitable for when you just left your computer inactive for 15 minutes. That goes double if you use encryption without TPM unlocking.
For leaving your computer overnight, hibernate wins on all fronts. I'm enthusiastic about sleep-then-hibernate schemes, but haven't gotten them to work on my devices yet.
Wow, it feels like this argument rewired my brain.
When I first read about the chardet situation, I was conflicted but largely sided on the legal permissibility side of things. Uncomfortably I couldn't really fault the vibers; I guess I'm just liberal at heart.
The argument from the commons has really invoked my belief in the inherent morality of a public good. Something being "impermissible" sounds bad until you realize that otherwise the arrow of public knowledge suddenly points backwards.
Seeing this example play out in real life has had retroactive effects on my previously BSD-aligned brain. Even though the argument itself may have been presented before, I now understand the morals that a GPL license text underpins better.
FWIW I like to explain it to folks like this: ignore all of your moral baggage around licensing and just focus on the fact that licensing is a legal tool of art that pretty much only becomes relevant in the context of threatening lawsuits.
BSD-type stuff is very simple because it says "here is this stuff. you can use it as long as you promise not to sue me. I promise not to sue you too."
Very simple.
GPL-type stuff is intrinsically more complex because it's trying to use the threatening power of lawsuits, to reduce overall IP lawsuits. So it has to say "Here is this stuff. You can use it as long as you promise not to sue me. I am only going to sue you, if you start pretending like you have the right to sue other folks over this stuff or anything you derive from it. You don't have the right to sue others for it, I made it, so please stop pretending and let's stop suing each other over this sort of thing."
Getting the entire legal nuance around that sort of counterfactual "I will only sue you if you try to pretend that you can sue others" is why they're more complex. And the simplest copyleft licenses like the Mozilla Public License have a very rigid notion of what "the software" is, so like for MPL it's "this file is gonna never be used in a lawsuit, you can edit it ONLY as long as you agree that this file must never be used by you to sue someone else, if you try to mutate it in a way that lets you sue someone else then that's against our agreement and we reserve the right to sue you."
Whereas for GPL it's actually kind of nebulous what "the software" is -- everything that feeds into the eventual compiled binary, basically -- and so the license itself needs to be a little bit airy-fairy, "let's first talk about what conveying the software means...", in various ways.
The interesting thing here is that as far as the courts are initially ruling, these from-scratch reimplementations are not human works and therefore are not copyrightable, which makes them all kind of public domain. Slapping the MIT license on it was an overstep. If that's how things go then Free Software has actually won its greatest sweep with LLM ubiquity.
I'm sure they wouldn't mind marking it as public domain. MIT is just the go-to license for things like this since it forces other people to notify others it came from an MIT repo if substantial parts of the original repo was used.
Yes, the entire point is that requiring Google's permission to sideload anything is very bad.
The linked post by F-droid additionally points out that even that very bad case is not certain. We shouldn't trust that Google will even allow sideloading at all based on their words on their own blog.
Media has a responsibility to report that there is no evidence that Google will even allow anyone to sideload at this point.
Well, I can't answer for @x42 (Robin Gareus) but for me personally the refactoring of the Editor code so that we could have multiple "editors" was both interesting and hugely challenging.
I didn't want to replicate the code we already had for the Editor, and figuring out to refactor this took a lot of time and experimentation and failures. Although there are still some rough spots, in general I'm very happy with how things turned out.
Clip recording was also a bit of a challenge. It uses an entirely different mechanism than timeline recording, and as usual I got the basics working in a couple of days, followed by months of polishing (and likely, quite a few more to go as we get feedback from users).
I've only used modern immutable Linux (Alpine, MicroOS) and wondered why of all places `/var/` was chosen as the location for rw stuff. It's fun to be reminded that there was of course a time when an immutable OS was the default, and you ran it off of floppies. So there's a lot of history to using `/var/` for that. Guess we've come full circle!
Was it immutable? I thought it was just different storage types, like you'd have a smaller disk for the root stuff and then make var on a larger disk. I'm surprised that, having something immutable, you'd choose to go the other direction.
Good point, considering the nature of floppies I suppose it technically mustn't have been immutable. But I feel like it would have been wise to mount your OS root read-only to prevent yourself from accidentally ruining your (possibly only) copy of your OS. At least before you had a reasonably sized hard drive.
> I'm surprised that, having something immutable, you'd choose to go the other direction.
I can somewhat imagine that having been limited by space and having to swap out disks all the time one would jump on the train of mutability without fully appreciating the benefits of immutability.
I think the issue with dependencies is a bit overstated. There's uv for that. And shell scripts have dependencies as well! You're not guaranteed to have bash, jq, and curl on a minimal install.
That being said, for real portability of programs that have slightly outgrown the script moniker I really like Janet.
> But what actually being banned is accounts, not access.
Is this implied, or is this detailed in the law? I can see why this would make sense. So many businesses just have a link to their facebook page as their business website, which you should still be able to view. And presuming platforms like YouTube fit the definition, banning kids from watching anything on there would be pretty rough.
> One might argue that this removes the algorithmic feeds. But I would wager that social media companies will just use browser fingerprinting to continue to serve algorithmic content to logged out users, if they aren't doing this already.
On the subject of YouTube, I wonder if they would allow for the creation of teen accounts, which restrict all social media functions but allow subscriptions. But would that then also remove algorithmic recommendations? What about data harvesting off those accounts? If so, I might have to look up how to get a teenage fake ID.
The vast majority do return carts in my country. But when you have 100 customers an hour (which isn't much) and 5% don't return carts that is 5 carts per hour - odds are you will always see a couple carts out of place. The numbers above are made up of course, but the point remains that a small minority makes everyone look bad.
Only one store near me has a coin deposit: Aldi which has European roots - it has probably never occurred to them to check if the cost of the coin collectors is worth it (I'm sure it adds $5 to the cost of a $300 cart). Every other store finds people return their carts often enough that it isn't worth the bother to put those in place.
And what country is that? If you're comfortable sharing.
Of course the coin thing somewhat relies on coins of mentionable value being in common circulation, which rules out the US from the start.
Here few people still carry coins since contactless, but most still have a fake euro coin somewhere on their keyring or in their car for shopping carts.
They hand out these fake coins, which are usually branded with the supermarket's logo, for free inside the shop. But the system still works because having to go inside for a new coin negates the saved effort of not bringing back the cart. And there's probably some feeling of discomfort associated with abandoning the cart with your coin still in it.
The US $.25 coin is similar in size to the .50 euro coin (about half the value). It is in common circulation and most people still have them. Most people I know keep a stack of them in their car for use in the carts.
> While we did initially start out on a single computer in 1987, the
> SDF is now a network of 8 64bit enterprise class servers running
> NetBSD realising a combined processing power of over 21.1 GFLOPS!
Which piqued my interest about how that compares to today's computers. nVidia's venerable 1080Ti from 2017 measures about 11300 GFLOPS, or 11.3 teraFLOPS. About a fifty times increase.
reply