You can usually get info about the upstream from the package metadata, e.g. on Debian:
$ apt info whohas
...
Homepage: http://www.philippwesche.org/200811/whohas/intro.html
...
The distribution model on Linux (generally speaking) is different from Windows, though, so I don't think it makes sense to view processes as fully "owned" by the upstream in the same way as on Windows. Instead of letting each individual organization directly have administrator access to rummage around on our machines and install packages, this is mostly delegated to the Linux distribution, which may customize the packages. (And of course the user has the right to customize the program as well, assuming it's FOSS, so ultimately the user is the owner of their own processes.)
Packages are not binaries. When I write software for Linux I'm not gonna sit there and wait for apt whatever to run in the background. That was the whole point of the sqlite db. Don't worry I poll the entire debian database.... and ubuntu ..... and fedora.... and gentoo.... . and arch..... etc.
The tldr is binaries on linux really should have org unit as a meta data field because when I write a task manager in C it needs to be fast.
Well, that validates my decision not to install it. Of course Microsoft will eventually abuse any trust you place in them and any access you give them. They always do. Don't let Microsoft run code on your machine and don't give them your data.
"When the DMA took effect, it expected gatekeepers like Apple to deliver interoperability by default [...] Instead, Apple created a request-based system where each developer must seek permission for specific features"
and
"the process can stretch across months or years before developers see any practical benefit, even though the underlying right to interoperability is already supposed to exist"
the process can stretch across months or years before developers see any practical benefit, even though the underlying right to interoperability is already supposed to exist
Not that I don’t think Apple is being petulant and maliciously compliant, but just because a politician passes a law declaring something to be so doesn’t mean that it is so. Apple built their platform for years assuming a lot of these things are and would remain private. When you design private APIs and locked down features, you make different choices and design decisions than if you make open APIs. Any interoperability was going to take months or years to get to, no matter what.
I tried keeping my comment very focused on one point that jumped out to me in the article instead of commenting on the whole situation. Their process, delays and circumvention of the intent of the law are indeed very problematic. They have been fighting the same fight with the same techniques on all fronts where they have to open their platform up. Disappointing but something that can be fought by governments and organisations at least.
Maybe I'm just misunderstanding the style of this article but at least to me the way how it presents it's critique, arguments as well as details of rejections feels a bit deceptive and overly broad while the reality is a bit more nuanced, even if the core of the critique is valid.
The online version has been extended quite a bit beyond what we broadly agree. If we translated back to checking ID in shops, it might look more like this:
1) Obviously you can't be trusted to handle your own ID card, because you could lend it to someone else or manipulate it in some way, so there should be a trusted guard with you at all times to manage your ID card for you and hand it to the shopkeeper.
2) Obviously you can't be trusted not to try to influence or attack your guard, so you must be kept in handcuffs for your own safety.
3) Obviously you can't be trusted with acquiring unapproved tools or meeting unapproved people who might enable you to break out of your handcuffs, so the guard must only allow you to communicate with approved people and buy approved products.
Conveniently and profitably, this also puts the company supplying the guard in a position where they can sell access to their control over you (as a consumer and as a source of experimental data) to their trusted partners.
> iTerm2 accepts the SSH conductor protocol from terminal output that is not actually coming from a trusted, real conductor session. In other words, untrusted terminal output can impersonate the remote conductor.
...which, the article strongly implies, but does not explicitly state, results in code execution on the local client machine.
But what about the case when it's working as designed, when the output does come from the remote conductor? It sounds like the server, where the conductor is running, is in that case trusted to execute arbitrary code on the client? Assuming the client doesn't use some sort of remote attestation, how can the remote conductor really be trusted?
My memory wasn't playing tricks on me after all - Suse Linux 6.3 had KDE 1.1.2 with several nice themes [1] - I'm pretty sure the version I used back in the day was SuSE 7 (a boxed copy, bought from Staples!)
Ah, perhaps I should have said "styles" rather than "themes"! I was thinking of the look-and-feel of the widgets, not the colors and window decorations. The widgets in all those screenshots seem to use Qt's Windows style.
> KDE's sophisticated theme support starts with Qt's style engine, which permits developers and artists to create their own widget designs. KDE 2.0 ships with over 14 of these styles, some of which emulate the look of various operating systems, and additionally does an excellent job of importing themes from GTK and GNOME.
I'm sure it was version 1.something that had the Bryce theme - I remember being annoyed that the scrolling title feature had disappeared when KDE2 came out.
But it's always possible that my memory's playing tricks on me.
Presumably they pay cloud vendors for cloud printing, cloud storage and cloud groupware, so to send something on the local network they simply send it to the cloud vendor and then download it again. That's what people in our office do. Very helpful for the cloud vendor's profitability.
It doesn't seem to support Mercurial though (not to imply that you were implying that it did). All I can find in this proxy/mirror thing to integrate it by presenting the Mercurial repo as a Git server:
https://peterlavalle.github.io/post/forgejo-actions/
reply