tenfingers

It's also a completely useless feature in the chip without the ability to setup arbitrary keys at boot time. This is the worst DRM incantation ever.

I expect AMD to clean up Intel's act on this.

I live close to switzerland's borders, and it's incredible the disparity in terms of salary/cost of living between switzerland and all it's neighbors.

I do not consider myself poor, but there's no way I can afford any sort of holiday in switzerland.

I have friends and some colleagues in switzerland: for them, a year's rent of my house would equal for roughly a single month of their salary. For those living close to Geneve, sometimes less.

It's mind-blowing, really.

Approaches similar to unexec() are quite common in lisp-like environments, so emacs doesn't come as a "surprise" here.

There's no reason emacs needs to use the glibc's malloc implementation though, especially given emacs has it's own built-in (and probably neglected) malloc for other platforms.

By Widget I mean any object which is a QWidget and is bound by some other widget (so I do not count plain QObjects) that you need for your UI.

ListViews are optimized for display of lists, obviously, so they generally instantiate only visible elements in the view, and delegates do not even undergo geometry negotiation so they're a bit lighter than a regular widget.

Still, if you do visualization or animation, the UI must respond within 1ms in order not to be noticeable, and that's very hard to attain with Qt5.

I doubt people using QML on mobile devices really understand the issue either, since when mobile developers speak of "animations" they generally mean some random transition of the UI itself. Often, the operation is not even performed in the background, but rather simply sequenced (so that the animation appears to be smooth, but the actual delay is completely absorbed by the user). In these scenarios, times up to 250ms/300ms might still be felt "instantaneous" as they're shorter than the transition. For me, it's outrageous.

If you have a classical desktop interface where you reach 100+ widgets (which sounds like a lot but is easily reachable with just a toolbar, some buttons and a form), the difference is noticeable when interacting even on recent hardware (i5+).

For example, since I work in visualization, I often tie data widgets to the GL canvas in order to provide realtime feedback. I also use Qt5 in order to provide keyboard accelerators. With QT5 the rendering latency grew so high that I couldn't provide realtime feedback anymore, and I had to batch requests (and finally reverted to Qt4).

Incidentally Qt5 widgets can be used in a GL context directly, but are way too slow to render and manage events to be used consistently at 60 fps (they're not designed for that, so their scope in this sense is not as broad as it can really be). It's actually faster to give them their own GL context in order not to interfere with your pipeline, which kinds-of defeat the point.

I've also found that the additional JS glue doesn't provide any benefit unless you go entirely QML.

Read their own introduction page. CopperSpice is a fork of Qt4.

Yes sorry, typo (fixed).

Note that C++ has "extern C" for the same purpose, and many people do not seem to be aware of it.

You can perfectly write a C++ library and expose a C-safe subset. I've done so many times.

The problem arises if you need to expose objects (with virtual methods), which C obviously doesn't have as the ffi is basically restricted to plain functions and record types.

Easy: just provide a certificate that cannot be changed within FF (must be modified by changing a file in the installation directory). No preference needed.

This would allow developers to roll their own, and organizations to allow their custom policy as well (which could mean that the privileges of the user himself aren't sufficient to change the cert).

There's really no reason as of why this couldn't be implemented properly. There' also no reason to not include a switch for it, really. This is all just smoke: most users have the privileges to change the FF binary, meaning that in most contextes malware has too (either through social manipulation or through exploits).

Add-On Signing which can be automated does provide very little added security for the user, and just serves as a big pain the butt for everyone else involved.

I'm routinely questioned to do support for users, and I find malware extensions regularly installed in Chrome which has even stricter requirements. The other day I found a laptop with one extension that redirected google.com to a scraper. Chrome did EVEN include a drop-down warning just below the URL bar that the homepage was being currently redirected by an add-on. Did the user notice? Not a bit.

In fact, Chrome adding a WARNING for it made me feel even more sad: they know this is going on. Is FF going to do the same? If I was an user with an extension that did that for whatever reason I wanted, I would be furious as hell to see an added warning which I need to disable (IF possible), and that will be ignored by most users anyway.

Malware developers will just get by faster, so Mozilla will not be able to keep up with the list of addons to blacklist. At the same time, initial approvals for legitimate addons will get slower. Reporting issues with Addons is clearly insufficient as Chrome Store demonstrates. In fact, I'm also NOT ok with the idea that extensions can be blacklisted at all, in spite of that "added security" aura around it. By the same logic, if extensions are required to be signed, then blacklisting (and blacklisting updates) shouldn't be allowed to be disabled.

And, let's remind ourselves, that most of the extensions I've seen installed were side-loaded with other software (with "extras") that was installed in the system with the same privileges of the browsers. So really, I do expect malware to simply patch the FF binary to either disable the check or change the public key, or change it entirely with a patched version.

I do not support walled gardens of any kind. Use a fork.

... or, you could ask everybody to walk, thereby "quadrupling" the effective capacity.

I've been in UK many times, and being able to effectively walk up all escalators due to the diligence of the people always impressed me. Coming from a country that doesn't have such respect for basic rules, it feels just wrong despite the gain of average efficiency.

Have you have ever used the "flex" nib? I wonder if anyone found some "use" out of it that couldn't be done by just pressure feel adjustment.

I do, yes. But the translator needs to be aware of the extra indirection to produce the text he needs, and between a custom layer and a standard formatting syntax, the second is definitely friendlier for anyone approaching translation, even when technically less powerful.

At some point the translator will have to format some string himself.

Do you have direct experience with it? Any improvements in the tracking quality of slow lines?