Hacker Newsnew | past | comments | ask | show | jobs | submit | eviks's commentslogin

Most of the information on the screen is the useless 101101, nothing utilitarian about it

It's "hidden"in the very first feature point

> Fast by design … powered by WebKit.


Is there at least one Rust GUI library without something basic broken?

It would have helped if you told us what you think is broken in Iced.

> Languages with strong type systems won't save you, good procedure will.

One of the items in the list of procedures is to use types to encode rules of your system.


> This first change was being rolled out using our gradual deployment system.

So they are aware of some basic mitigation tactics guarding against errors

> This system does not perform gradual rollouts,

They just choose to YOLO

> Typical actions are “block”, “log”, or “skip”. Another type of action is “execute”,

> However, we have never before applied a killswitch to a rule with an action of “execute”.

Do they do no testing? These isn't even fuzzing with “infinite” variations, but a limited list of actions

> existed undetected for many years. This type of code error is prevented by languages with strong type systems.

So this solution is also well known, just ignored for years, because "if it’s not broken, don’t fix it?", right?


Because it's not limited to games, forcing updates cuts of a lot of apps that can't invest enough in updating.

Also the barrier to use you're suggesting with alternative install/emulator is pretty high for an average user. It also breaks integration with everything else (e.g., a simple alt-tab will show the VM instead of 2 apps running inside)

Also because a lot of progress is regression, so having an old way to opt out into is nice


Integration is the biggest thing. While some desktop VM hosts provide various integration bits like file sharing and rootless window support, the experience is rarely seemless.

Drawing a few examples from an old Raymond Chen blog post[1], integrations required for seemless operation include

• Host files must be accessible in guest applications using host paths and vice versa. Obviously this can't apply to all files, but users will at least expect their document files to be accessible, including documents located on (possibly drive-letter-mapped) network shares.

• Cut-and-paste and drag-and-drop need to work between host and guest applications.

• Taskbar notification icons created by guest applications must appear on the host's taskbar.

• Keyboard layout changes must be synchronized between host and guest.

These are, at least to a useful degree, possible. Integrations that are effectively impossible in the general case:

• Using local IPC mechanisms between host and guest applications. Chen's examples are OLE, DDE, and SendMessage, but this extends to other mechanisms like named pipes, TCP/IP via the loopback adapter, and shared memory.

• Using plug-ins running in the guest OS in host applications and vice versa. At best, these could be implemented through some sort of shim mechanism on a case-by-case basis, assuming the plug-in mechanism isn't too heavily sandboxed, and that the shim mechanism doesn't introduce unacceptable overhead (e.g., latency in real-time A/V applications).

Finally, implementing these integrations without complicated (to implement and configure) safeguards would effectively eliminate most of the security benefits of virtualization.

[1] https://web.archive.org/web/20051223213509/http://blogs.msdn...


> forcing updates cuts of a lot of apps that can't invest enough in updating.

What about emulation?


emulation is addressed in the next sentence? Also see the sibling comment with more details on the list of issues if you "simulate" the OS instead of using the real one

It wasn't before, when I asked. Yes now there is more here about emulation :).

> Bugs exist, and they're sometimes fixed more slowly than we'd like, but given the size of the GitHub ecosystem this is probably just one of many outstanding bugs.

Sorry to be blunt, but you've said nothing of substance. To address the actual criticism you need to explain why these specific "inexcusable bugs" they cite are excusable from your perspective. Otherwise if the whole website doesn't function for months your statement "bugs exist, fixed slower than we'd like" would also apply and be just as meaningless


There was no mind change, just a change in published words from a true expression of his mind into a more bland corporate speak

Yes, of course, many people use the same shortcut for the same action in all the apps

How does Windows without such force to contribute code back have better drivers?

I imagine because the Windows team at Microsoft have an annual budget measured in billions of dollars.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: