samus

Stock Dark Reader browser extension works well for me.

Not really; `-type app-image` merely runs jlink and is intended to let you edit the bundle before calling jpackage again and create the installer. You need the tools from appimage.org for the final step.

Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.

Accessibility apps naturally require privileged access to other applications. Using the clipboard for accessibility is a hack though, as its intended purpose is occasional generalized data transfer. Also, Zoom isn't an accessibility app in the first place, and all capabilities it needs should be opt-in.

Unix systems were initially designed to be multi-user systems (as in multiple meatbags accessing a mainframe across terminals), in an era before it was common to indiscriminately download and run applications from the internet. Files required explicit opt-in to become executable. There were always attempts at mischief, but it was deemed sufficient to separate user account from each other and denying direct access to the hardware so an account compromise wouldn't escalate to the rest of the system.

Because of this heritage Android uses user accounts instead of namespaces a.k.a. containers (a much newer and less mature concept) to isolate apps from each other.

That's very telling about the quality of the security audit.

It's not about Linux.

Unfortunately making software easy to install also makes it easier for Malware to be installed. It's a classic dilemma that is only fixable by making the user think twice about running stuff from the internet: Unix requires making the file executable, Windows at some point started tagging downloaded files with an "untrusted" attribute.

> I thought Apple's tool was ridiculous though. It's like "oh, some trash blew into our yards from the neighbor's trashcan" so Apple replies "oh, don't worry, I destroyed it with my orbital ion cannon" and the tech community never stops to wonder if maybe it's a little strange that Apple has an orbital ion cannon and maybe we should ask some questions about the ion cannon.

Nah, that's very on brand with Apple. The Apple ecosystem is well-known to be a walled garden where they rule and are very stringent about separation to the outside and being in control. People who use Apple products know what they are getting into.

Unless you have to run the meeting.

Quite hard because on Linux there is no concept of "apps". There is a (very flimsy) separation between processes, but the strongest actual security boundaries are between kernel and user space as well as between users. Namespaces are explicitly not acknowledged as such, which limits the security guarantees that containers can provide.

Snaps and Flatpak are steps towards that goal, but there are many issues surrounding these technologies, and many apps require sweeping permissions to work well since they were not initially designed to be limited in that way.

There is no install time in Java. If you want something to happen at install time you'd have to ship a shell script with the installer that does a brief training run when the application is first started.

Even if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.

Jpackage or jlink should be extended to support creating AppImages.

How much of these 3s is javac? JEP 544 will only help reduce javac's overhead, not that of the compiled program.

It can and already does. It mostly depends on the GC. Or do you mean non-heap memory that the runtime uses?

> i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.

What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.

That won't be necessary when 544 lands. The only thing you'd gain is not having to ship the JIT compilers in a jlink build. Also, I'm fairly certain that the JIT compilers can be turned off with some combination of runtime flags to ensure only the AOT generated code is executed.

IMHO the most interesting feature of OpenJ9 is the compile server. One node decides to optimize, sends over the traces, and the compile server sends optimized native code to all nodes. Or a new node joins and could be brought up to speed within a very short time.

One could also just use jlink and extract the zip file that it produces.

It would have been more precise to say O_DIRECT instead of io_uring. The point of io_uring is to avoid syscall overhead. What they were after was actually managing a page cache on their own, and it turned out to be more complicated than they thought.

> > Getting one's hands dirty has little to do with cleanliness inside the home. Do you think the Japanese didn't have to do farmwork?

> Thank you for agreeing with precisely what I already said.

Except that the discussion was never about that, but about cleanliness inside the house. You then went off a tangent with that BBC article.

> I didn't say, elude, or mention that it was. Instead, I said 'city dwellers' are afraid of dirt.

And the discussion was also never about people afraid of dirt. That's something you brought up to "muddy the water" and lead the discussion astray.

Murphy was in general so dismissive of his own talent. Granted, he lived in the era before people played chess for a living.

I got by fine with a debit card. But of course it can be inconvenient since they usually lock quite a large charge as a deposit, which gets released when everything turns out fine.

Discounts on volume deals are yet another thing since a higher volume helps the business exceed the break-even threshold faster. Also, volume deals have a favorable management effort to income ratio compared to single transactions.

Huge numbers reduce manufacturing costs, but only because they justify investments that are uneconomical at lower volumes. The business would still go bankrupt if they don't read breakeven.

Economies of scale are a real thing and not just because of monopolies wanting to deny new incumbents.

Getting one's hands dirty has little to do with cleanliness inside the home. Do you think the Japanese didn't have to do farmwork?

Contamination is not a modern concept either. Cue to how many religions have quite sharply defined criteria for ritual cleanliness.

It's significant to the Church, but less so for Chinese authorities, who could always decide to establish their own state Church.

Then they are not smart TVs anymore. More precisely, they couldn't offer the features one expected from such. Think about a smartphone without internet connection.

The issue is moot since nowadays local practices are accepted to a degree. Even if Rome decided to go back on that it would have little practical relevance nowadays since there are lots of branches of Christianity that are not in communion with Rome and who are perfectly fine with that.

I just don't get why you treat this as something super complicated. There is street and nature level dirt which contains an unknowable degree of contamination that can be unambiguously bad for you if you ingest it, no matter what that BBC article says, and the inside areas where people eat and sleep. The vast majority of cultures prefer to maintain that separation and to maintain a considerably higher level of cleanliness in the living areas, no matter if it's not at semiconductor fab level.

Specific to Japanese culture is just that they prefer to sit at low tables and to sleep on the ground on duvets; it should be easy to see why they want less dirt on the ground than other cultures.