Their AI solution is all about trust, he says, and we can trust Mozilla because they're not incentivized to push any particular provider. But all we're trusting them with is a frontend for other AI providers, which really doesn't help much since the backend provider also needs to be trusted.
But wait! Since Mozilla is trusted, they're also going to provide their own AI backend service. And they're going to do placement deals with AI providers. Which of course incentivizes them to favor their own services and their partners, which nullifies the CEO's stated basis for trusting them, which makes the whole thing pointless.
A solution to what? Aside from details of the implementation, one can also disagree with the framing of the problem and scope of the solution. Sure, we're free to implement an alternative solution for doing DNS resolution and IPC and logging and time synchronization and job scheduling and service monitoring and ... but should there be a single solution to all of these things at once?
All of the things you mention are interdependent, as resource and service management is the core of it all. I'm convinced that they set out to design somethign that has a scope which is as small as possible, but then noticed that interfacing with legacy-but-established open source software was extremely difficult.
I'm very thankful for systemd covering more and more bases because the "common" alternatives for many problems might be stable but they are often really bad to configure, maintain and debug - the ergonomics in non-default use cases have a lot of potential for improvement. And what can you do if the maintainer is not responsive to the kind of improvements you would need to make the software ready for the next decades? Many times I have forked things and tried to refactor their technical debt so a new feature can be implemented without making it an even bigger hack, and after that you just want to delete it all and start from scratch with a "proper" setup.
So I can understand the perspective of the systemd developers and the pain they had to go through simply on a technical level, not even thinking about the huge flamewars on mailing lists with some people.
Open source has big social dynamics, and a certain type of person is attracted to being "leader" or maintainer even though they are not as technical as I would wish them to be. I've had the painful experience with having to explain security vulnerabilities to some of them and my idealistic illusion of open source project governance received a good grounding in reality.
On top of this imo the documentation of systemd is really good.
It's literally not a single solution. systemd isn't a piece of software, it's, like, 20 pieces of software.
People who think the init system is doing all of this have just not done even the bare minimum amount of research on the topic. Although, granted, the naming might not help.
Right, I guess I shouldn't have edited out my preemptive response to this: Of course the solution is internally composed of different parts. Most things are. People of course understand that those internal parts could be switched out for new parts that perform the same role in the overall solution, but that doesn't help when the disagreement is about the scope and purpose of the entire solution.
When people talk about systemd being a big ole monolith against the unix philosophy this is usually what they mean. And it's just not true. Like, theres no argument to be had because systemd is many pieces of software that do one thing.
My point was there is no systemd software. Systemd is a project naming convention with many projects under its umbrella that do not rely on each other in any way.
It's sort of like saying KDE is a whole thing because it has a text editor. Uh, no - KDE is a project, Kate is a text editor part of the k applications suite, which has nothing to do with plasma, the desktop shell. You can use Kate on any shell. You can use plasma without Kate.
Isn't unified agency the point of forming an organization? The organization generally elects leaders to direct the actions of the organization for some common purpose, e.g. through policies and direct decisions, and they can (or should) be held accountable for those actions.
Couldn't the correct function signatures be generated from the COM type library? Using an LLM for this is clearly not a good fit, as the article demonstrates.
LibreOffice is derived from OpenOffice.org which is derived from StarOffice which predates Java. When it was acquired by Sun and open-sourced, they added some optional components implemented in Java, but the core application is not a Java application. The GUI is not Swing but their own custom GUI framework (not based on Java).
Never mind the December security patches, Samsung haven't even released the November patches yet, the ones for the critical severity RCE. Unless you have a "major flagship model" [1], because apparently only the richest users deserve to be secure.
Why would you want security, if you get 'play integrity' for phones that received no updates since 2 years. Google's current security practices are more than dubious IMHO. Now they are not releasing any source for security patches for 3 month, to 'protect' vendors that are too slow updating. As if there is no chance for bad actors to reverse engineer those patch sets.
I have the strongest level of "Play Integrity" on a Xiaomi phone that hasn't received any updates since the beginning of 2020. Google Pay and co work fine. It makes sense when you remember that PI is not about security at all, that's just an excuse.
Elaborate please. PI on its own is just an insurance API for banking and similar apps to ensure that they can do secure compute on the device. It can also be used to check if the device that the app is running on is a genuine Android device, since no VMs or custom ROMs can pass hardware integrity.
Very old, unpatched and rooted devices can fairly easily pass device integrity check.
It primarily assures the software vendor that the phone is running Google buttplug in the privileged mode.
Remember, handsets running on ANCIENT versions of Android with no patches for years. Whilst seems to be important to raise under the Forbes article (rightly) fussing about a couple of zero-days.
"Custom roms" (whatever that means) can easily spoof the checks in the specific situation (mainly hardware that allows for several things).
What sense is does it make to certify an insecure device that may be subject to all kinds of remote exploits and elevated code execution as 'unmodified'. The argument of the banks is: the device is insecure (even with the latest patches). We all know the whole compliance is a bit more complex, so it might make sense on that level...
Pixel 6a used to show a September patch as the latest, but tapping "check for updates" found a new one. As mentioned in other comments here, apparently tapping those buttons twice may help.
Says September is the latest system update. Click check updates, says it's up to date, click check updates again, says it's preparing system update and hangs out for a while - then says it's downloading and installing a 781M update.
WTF?
Update: OK finally the update completes an hour later, even the reboot took longer than usual - says it's "updated to December 5, 2025"
This phone running Android 16 for a bit over a month now.
The December updates for Pixel 7 and Pixel 7 Pro are available to manually download on Google's website [0], so the updates do exist, although Google might not be rolling them out to the general public quite yet. But the December update for Pixel 7a are completely missing from that website, and trying to update from the Settings app also shows no updates available.
There are instructions at the top of the link. You need to use "adb" from the command-line on a computer, but it won't wipe any of your data, so it shouldn't cause any data loss. If you don't want to use "adb", you might be able to use [0], but I haven't tested it myself.
Rumor is the Pixel 7a December update rollout was paused due to a severe wifi bug. You might not want to upgrade manually at this time, even if you find images available for download.
(The rumor is somewhat weak, it's apparently everyone regurgitating one seemingly AI chat.. Google needs to state the reason publicly.)
I thought Google was moving stuff out of the open source stock android branch and into their proprietary pixel development branch, such that the functionality of stock android has been diminishing to the point that a phone running stock android would be barely usable as the device we'd expect. Maybe I've read wrong and misunderstood though.
The funny thing about the last one is that those actions ultimately boil down to invoking their CLI tool (which is pre-installed on the runners) with "gh release create ...", so you can just do that yourself and ignore the third-party actions and the issues that come with them. Invoking an action isn't really any easier than invoking the CLI tool.
Yeah, what really needs to happen with that repo is to put that in the README to use the gh CLI instead of pointing to the third-party action with questionable security policies. If they were accepting PRs for that repo, it would be an easy PR to make.
> post your applet on a web page, and anyone on the planet could run it instantly
"Instant" is a strange choice of words to describe JVM startup performance. I recall the UX of encountering an applet involving watching a Java splash screen while the browser is frozen.
The alternatives to Java were just as bad. Flash and friends were fast but couldn't do anything more complicated than animation for most of its life. In the Java heydays, you were doing either Java or custom ActiveX plugins, and both led to security popups galore and random browser freezes.
However, ActiveX usually required you to install components, while Java could just run first time.
What I would really like is a Git equivalent to Mercurial's "fold" operation. I usually make a bunch of commits as I work, just as checkpoints, which I then want to turn into a single final commit when it's done, which could be quite some time later, e.g. "started on thing", "broke it", "broke it more", "Add thing to improve foo of bar".
Mercurial's "histedit" command offers two operations to combine the commits: "fold" and "roll", where "fold" brings the earlier commit into the later commit and "roll" does the reverse. The "fold" operation does exactly what I want in this case: It brings all the changes into the final commit from when I actually finished it, using the commit date of that commit.
Git's "rebase -i" command offers "squash" and "fixup" and "fixup -c" and "fixup -C", but they all do the same thing as "roll", i.e. they keep the earliest commit's date, the date when I started working on the thing and not the date when I finished working on it. (So I then cut and paste the correct date and update the commit afterwards. This may not be the best way to do it.)
That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started.
One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too.
At the very least, you can do your hand editing of the commits during the rebase instead of after by switching the earliest commit from "pick" to "edit" to have the full power to amend the commit before it moves on (with `git rebase --continue` when you are satisfied). (Versus "reword" if you just want to change the commit message only.)
Also, instead of naming commits things like "broke it" and "broke it more" an option is to use `git commit --fixup={previous commit hash}`. That auto-generates a "fixup!" name based on the previous commit and auto-marks it as a fixup if you use the `--autosquash` flag to rebase.
I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit.
But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningful as "broke it", actually. Maybe most people wouldn't even bother making these commits – or maybe they would if Git supported "fold".
My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time.
Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces only once they feel complete and start to tell a story. (And in those cases I may use a lot of `git stash -u` and `git stash pop` snapshots, too, especially if I need to switch branches in that worktree.)
Hmm, I may have actually solved my problem. I think what I mostly want to do is this, if I'm working on the "feature-1" branch based on "main":
$ git checkout feature-1
$ git reset main
$ git commit -a -C feature-1@{1}
This squashes all the changes and keeps the date and and message of the final commit on the branch.
Weirdly, although the "-c" and "-C" flags for the fixup operations sound like they should correspond to the same flags for "git commit", which grabs the date along with the message from the specified commit, the fixup flags only affect the message and not the date.
It would be nice if it worked the same for rebase as for commit. Then "fixup -C" would essentially correspond to Mercurial's "fold".
Ah, yeah, that use of `git reset --soft` is how many places do squash merging, so that makes sense. You may want to make sure to include the `--soft` flag explicitly just as a precaution.
Also yeah, I would expect the fixup -c and -C flags to be more aligned with commit in a rebase.
git fixup doesn't take the old commit message either, so I would be not so surprised that it doesn't take the commit message. It is really for preparing to do rebase fixup to the older commit.
How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":
$ git checkout feature-1
$ git rebase --update-refs main
Successfully rebased and updated refs/heads/feature-1.
Updated the following refs with --update-refs:
refs/heads/feature-2-base
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
Their AI solution is all about trust, he says, and we can trust Mozilla because they're not incentivized to push any particular provider. But all we're trusting them with is a frontend for other AI providers, which really doesn't help much since the backend provider also needs to be trusted.
But wait! Since Mozilla is trusted, they're also going to provide their own AI backend service. And they're going to do placement deals with AI providers. Which of course incentivizes them to favor their own services and their partners, which nullifies the CEO's stated basis for trusting them, which makes the whole thing pointless.
reply