cm3

How relevant is that metric given that users will predominantly use the mobile app?

Speaking of UI regressions, Chrome's text input fields hijack Ctrl-Shift-Del, so you have to leave those controls before you can use the existing and standard key binding to invoke the clear settings dialog. Opera has the same bug, but Vivaldi, maybe because the UI is written in HTML, doesn't hijack it and the keybinding works globally in Vivaldi.

Because I don't want to open a new browser window because I closed the last tab and there's no Close-other-tabs key binding, just a menu item, if I were to emulate the behavior by closing all other tabs, optionally clear history and navigating to somewhere else in the current (now solitary) tab.

I wish Chrome would adopt Vivaldi's and Opera's feature to not close the window if you're closing the last tab. This works nicely in Firefox, Opera and Vivaldi, and I always accidentally close Chrome. I've seen Chrome extensions for this, but they don't do this properly and take up considerable memory for something that should be a core feature.

They are customizable in Vivaldi (https://vivaldi.net/en-US/teamblog/162-mouse-gestures-to-the...), another browser, which is made by ex-Opera folks, include the CEO and former core devs. I'm not saying one is better than the other, but Vivaldi is also Blink-based and has been restoring other Opera 12 features than Opera Opera has.

Their system daemon project's thesis: http://www.helenos.org/doc/theses/mk-thesis.pdf

Thanks, you're right, found and disabled all but two specs and tuned minimum to 3 which is TLS1.2. Will put those in the locked config file, so that they're read-only at runtime.

And Firefox 52 is proposed to default to TLS 1.3 for safety and performance reasons: https://groups.google.com/forum/#!topic/mozilla.dev.platform...

I wish it was still possible to override these per profile. Last time I tried, the knobs were gone and had no effect whatsoever to enable safer defaults. I used to be able to force a minimum TLS version and enable only select few ciphers.

In case you're wondering about the different linux kernel bypass mechanisms, here's the relevant slide from a recent talk: https://lh3.googleusercontent.com/TO1UdUicn1wuF4jIAhskikO6ML...

Sorry I haven't found the actual slides yet, that's why it's a photo from someone who took it while attending the talk.

> I'm afraid not. That was David Fincher/HBO and it's not going ahead.

I'm glad they won't, because the risk of ruining it is too high as proven time and again.

And AUTOSAR (to someone unfamiliar with its details like myself) seems very complicated, although it's probably warranted.

Why isn't GPS plus lidar and friends enough, give that the map data is already available in detailed resolution on local storage? Internet isn't yet as pervasively, reliably, always available as it should be, so I wouldn't want to wait for a connection in my autonomous vehicle while I'm on probation and have no license.

I'm counting the days until cars will be weaponized remotely via rich text message received on your onboard entertainment/computer system which isn't physically disconnected from the vehicle controller because it at the minimum accesses status info.

Some grave accident is the only way mandatory minimum standards and improvements will be had, unfortunately. It would be enough to disable breaks remotely for regulation to appear.

It's ironic that (semi-)autonomous driving will improve safety, while all the added software and network connectivity will accelerate the need for software quality requirement as used for airplanes, because software defects will be deemed lethal. I really hope it will happen before someone or something remotely causes a vehicle to cost lives. That said, I suppose a vehicle would turn off the motor if everything else (sensors, actuators, ...) fails.

Genuinely curious, do they not teach historic designs in EE course plans? To learn from and improve, but not reinvent something half-way or worse. Also, older designs are much easier to study completely compared to the super complex logic inside your current day x86.

Personally, I would call it hardware-assisted gc if we consider hardware acceleration to be things like GPUs, crypto accelerators, etc.

For the mentioned group's fears. It must be based in some defining event, no?

I haven't been to Asia (yet), but I can say that in the "Western World" courts are overloaded with cases that should probably not go further than your local ombudsman which in itself is a very old concept found in millenia old civilizations, predating the court system as we know it. This is probably why courts in the US have quick processing of a group of independent, alleged criminal offenders. It's unfair to those accused of breaking the law as it is to the lawyers and maybe even the judge who has to decide in two minutes whether the accused should go to jail/prison while the case is progressing. I'm afraid to suggest fixing the latter, because law enforcement organizations would likely push for legislation to make it quicker and easier to put people in real prison without a hearing or trial.

Curious, is it possible that the restrictive Soviet rule (beginning with Josef and ending with the death of Brezhnev or, if you will, Gorbachev's glasnost+peretroika) caused this, or does it go much further back to Zarist times? What's the underlying explanation?

Burroughs line of machines and Intel iAPX 432 and it's derivative i960 (which is actually in use). The project for which the Intel CPU was designed together with Siemens would have given us a safer foundation due to using this processor in an Ada based operating system in the 1980s. But then UNIX won and gave us the hegemony of C and all the avoidable security bugs associated with it. Lisp machines had similar designs. These days there are RISC-V designs that have similar features. Just like DJB has been wishing for a few extra arithmetic instructions for crypto in x86 processors, I wish for instructions that would make garbage collectors more efficient and also provide support for memory safety features.

https://en.wikipedia.org/wiki/Intel_iAPX_432

https://en.wikipedia.org/wiki/Intel_i960

https://en.wikipedia.org/wiki/Burroughs_large_systems#Tagged...

http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

I'm sure there were similar design in the 1990s, but I don't have references ready off the top of my head like the above.

I'm not talking about Rust lifetimes but lifetimes as a common term used in many languages. What I mean is that in Rust you're forced to explicitly deal with the lifetime aspects of variables before the compiler will generate any code. In C and C++ you're free to skip that and introduce leaks or use after free bugs, which are accepted by the compiler due to the language definitions. I didn't mean to say it's more difficult. In fact, it's less work to deal with these issues in Rust before the code gets generated rather than debugging mysterious bugs. Put differently, you're debugging your code while trying to compile it instead of debugging it after hopefully someone was able to trigger it and provide enough clues for you to identify the issue.

Which shouldn't be hard since most scientific libraries rely on a standard body of Fortran code being reused underneath. The nice bits are the interactive development environment, or visual repl if you will, and Rust could reuse the efforts of Servo here to make something shiny and comfortable that is easier to get running than existing solutions on many platforms.

The hard part doesn't go away with unless you pull in a GC or something similar to take care of lifetime bugs. In Go you always use a GC and circumvent the explicit lifetime management syntax of Rust. Some data structures are very hard to write without something akin to a GC, so my bets are on a few opcodes trickling down into mainstream cpus making GC easier to implement in optimal time and space. I'm surprised Android hasn't forced anything like that in their supported ARM designs, since such cpu support has been available in production systems in the 1970s and hence isn't anything revolutionary, just not on the radar like vector instructions have been.

> Rust should integrate easily with C++ code

The day that Rust manages to have always up to date Qt bindings that do not force you to make compromises compared to the C++ API, I think the C++ support will be at a comfortable level. Right now there are fresh efforts in the Rust and Haskell camps to solve this cleanly in a modern way. It would certainly help if the consumption of C++ APIs via llvm (which is used a lot byt Rust) was made a first class feature like you can import and export C APIs. Exporting C++ classes is a whole different story and may not map in any reasonable way to Rust modules or crates.

There's enough unexplored for a season 3 story-wise.

I heard they will make a US version. If it's like Shameless US, I'm all for it, but usually US remakes tend to make a bad copy that also stretches out for no reason. I really like the British and Australian format of a few dense episodes rather than 12 or 22 US episodes where it's 60% filler material. However, if it isn't story driven, then making 22 episodes is ok.

After the bad US copy of Rake tanked, the Australian original got a 3rd season, and it's likely to get a 4th one, so sometimes studio heads make sound decisions.

I wished that they had expanded further on the past as in Utopia S02E01 but they unfortunately didn't. The conclusion was satisfying, though.

I wasn't too affected by the previous seasons and haven't watched Season 3 yet (except episode 00 pre-netflix with Mr Mad Men), but if you're up for it and really want to feel emotionally exhausted after a motion picture, I can recommend Denis Villeneuve's Incendies (http://www.imdb.com/title/tt1255953/). If Lost in Translation leaves you disillusioned, then Incendies will be a punch to the stomach you feel for another day. It's one of those rare movies you appreciate and regret watching at the same time. A longer running movie with similar themes (I mean mini series) is the UK production The Honourable Woman, but it doesn't leave you as emotionally affected, so I wouldn't recommend it as a must watch.

Thanks, I was really confused when I read the title "Massive Dyn DNS outage" and how that affects Twitter or Github.

Just to be clear, this is a DDoS against Dynect's NS hosts, right?

I'm confused because of the use of "dyn dns", which to me means dns for hosts that don't have static ip addresses.

I'm actually surprised so many big-name sites rely on Dynect, which I hadn't heard of, but more importantly don't seem to use someone else's NS hosts as 2nd or 4th entries.

What am I missing by not using a manager?

I've been doing something like this

  set rtp^=~/.vim/bundle/ScrollColors/

for each plugin, and it works wonderfully, doesn't complicate things, plus never broke.

Granted, I don't auto-update plugins but go into each git repo and checkout the desired release tag (or some revision) if I need to.

Are the system (not app) updates Google releases applicable to all Android devices?

It's true that there are a high number of bugs available just in mobile browsers, which do receive google play updates, if you have google play, but viewing the underlying code as verified to be correct would be naive.

If I know that a smart phone or smart fridge will not get software updates and be substantially limited in functionality by that, I wouldn't pay more than 100 bucks for it, because I expect to buy another one in probably 14 months.

However, if the update problem would be fixed properly, I wouldn't mind paying a premium.

It seems that this isn't just laziness by the vendors but also calculated into nudging customers to buy new appliances and gadgets although the hardware is capable and perfectly fine. No vendor would admit to that, but this is being investigated and called planned obsolescence. If the price would reflect the artificially limited lifespan of a device, then the problem goes away, and it's just a matter how much of the materials gets recycled.

Since for any serious bug that's published, there's very likely a dozen private or not-yet-found, and also considering on how many networked devices the linux kernel is used, I would really like to see a better upgrade story for Android devices and any other linux-inside gear which doesn't have a distro package manager to apply the fix. As little as I like obstructing tech companies with more laws, especially since most laws don't understand the tech, I feel like laws are the only pressure we can hope for. This is why the abuse of IoT devices is a good thing. It will highlight how dangerous it is to slap a random linux version in some device and never bother with updates. A fleet of smart tvs needs to be hijacked with a stalker trojan that is then used by people to record and later post online private moments of unsuspecting owners of always standby smart tv, amazon echo networked microphones, etc. It's just how the world works before it realize the risks and does something about it.

As an engineer you can argue and plead with management to not release something that you don't intend to provide timely updates with a well-communicated support time. Like a 2 year warranty that's prominently communicated, this would highlight to consumers that it's unsafe to use the device unless disconnected from the network. Just like a car that doesn't pass your local safety regulations is not allowed into public traffic.

Actually, I'm surprised modern cars do not require periodic zero-expenses-for-the-owner software updates at licensed dealerships. You can explain to a driver that tires go bad because they drove X miles and have to be paid for, but you cannot argue that software updates need to be paid for because from the time they bought it Y days have passed. Take the Samsung battery optimization that went wrong, where the separation layer was a tiny bit too shallow. It's fair to assume some regulation will follow for safety purposes. Similarly, networked devices, which are not (and cannot be?) microcontrollers with mere 500 lines of code, have to be regulated in terms of software updates.

Now you may say the industry will go broke if they're required to provide upgrades, or less devices will be made, but I think this will lead to consolidation of the software stack, which is mostly a good thing, as those who want to produce dozens of cheap IoT devices can do so without hiring kernel developers. It's like other industries where cheap toy makers source materials like plastic from vendors, knowing it's safe, or create the materials following a detailed recipe which is certified.