No, it's similar to letting someone else do all your hammering because using a hammer is too dangerous. And then, to make the process more efficient, letting them take control of your home to be able to provide hammering services while making sure you can't touch the hammer.
I don't think that would work, as capslock should only affect the letter keys (not e.g. turn "1" into "!") and the keyboard doesn't know which those keys are, as it depends on the layout configured in the OS.
Are you sure Java's UI issues are caused by threading and not just Swing being a glitchy pile of junk?
For example, if you don't explicitly call the java.awt.Toolkit.sync() method after updating the UI state (which according to the docs "is useful for animation"), Swing will in my experience introduce seemingly random delays and UI lag because it just doesn't bother sending the UI updates to the window system.
No, JetBrains use Swing in IntelliJ IDEA. You can tell from how it (for example) fails to layout dialogs correctly the first time they're displayed, just like every other Swing application. And how windows have no minimum size because Swing doesn't expose that functionality. And the various baffling bugs involving window focus that are inherent to Swing applications.
Eclipse uses SWT instead, which wraps the platform's native widgets.
When did you last use IntelliJ, 30 years ago? I've never seen it fail to lay out dialogs correctly, windows do have minimum sizes, and I haven't seen any focus bugs.
This might be specific to X11. The initial size of the window is miscalculated when it first opens and a moment later changes by a few pixels, causing the contents to visually shift slightly. This happens with dialog windows the first time they're opened.
> windows do have minimum sizes
My mistake, I meant maximum size.
> and I haven't seen any focus bugs
I was being a bit vague because I've seen lots of different focus bugs on different platforms both decades ago and very recently. For example, it used to be that on Windows, the focus would change to the wrong window if you alt-tabbed too quickly. On X11, very recently, I've ended up in states where the window somehow has focus but not keyboard focus, among other things.
In Sun's own Wireless Toolkit (for J2ME development), which was a Swing application, the keyboard navigation didn't work until you opened a dialog window for the first time, after which it started working.
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?
No, it's similar to letting someone else do all your hammering because using a hammer is too dangerous. And then, to make the process more efficient, letting them take control of your home to be able to provide hammering services while making sure you can't touch the hammer.
reply