Someone has made Apple Watch do something actually useful!

The only practical consequence will be that now you will have to carry a proprietary dongle/adaptor that will convert from USB to the usual analog jack, because being tied to the universally crappy headphones commonly sold with the phones is going to be even less popular than this.

BTW, the USB consortium actually explicitly discourages putting on USB jacks on the headphones themselves in the spec.

I think the consumers will vote with their feet - fragile, expensive proprietary dongles that you need to carry only so that the manufacturer can save a few cents and millimeters in the phone are not going to be popular. They never were - like the early phone camera add-ons which were in this form.

I wouldn't be worried about DRM here. Who is recording music through the analog jack of their phone?? And pretty much nothing else is concerned - purely digital analog interfaces for computers have been around for decades and have never managed to push out the purely analog interfaces. People simply want to connect their stereos and loudspeakers. The only reason for this is cost cutting and space saving - especially Samsung and Apple are taking this to the extreme at the expense of usability.

The problem is that this directive does not achieve that. The only thing you get (also here on Slashdot if you are in EU) is an interstitial asking you to accept the privacy policy/TOS/cookies. And then it is business as usual, with those 9000 random cookies, evercookies, adverts and pingbacks.

This law is addressing the symptom (cookies) and not the cause - companies wanting to hoard, mine and sell their visitors' data.

This stick is going to be woefully underpowered for Windows. It has only 4GB of RAM - that will barely run Windows alone.

And Windows on IoT SoC boards - why? Windows only makes sense if you want to exploit the Windows development ecosystem. Which is nonexistent for those small IoT boards. So you can as well put Linux or an RTOS on it and save power, licensing costs (should you decide to sell you widget) and support nightmares.

Well, considering that updating maps in the built-in satnav of my boss' BMW can cost around 800 euro (old car, proprietary satnav, proprietary maps, not user updatable, so service costs on top + margin), this is just going to be a nightmare.

The good thing is that these idiocies will be targeting primarily the premium (= expensive) car segment. The low end clunkers most people drive will be stuck with "tablets" for their AC controls at best.

Vivaldi is built by the same people as the original (before it became a "skin" for Chrome) Opera was, so the design and features are not really surprising.

I wonder what will we have to sell to be able to use this browser, though. Aka, how is Vivaldi going to make money with this "free" (as in beer) browser?

I am not sure how this post got moderated "Informative".

Sorry, but you are seriously ignorant about how Linux package repositories work. There is not GPG signature "audit trail". Only the packages uploaded to the repositories are signed. The distros only package the code - do you really believe (and trust) that the person who has compiled and signed the package has actually verified that it is malware free? Or that everyone who posts whatever code to Github or wherever else where the distro gets their software from is required to GPG sign it so the changes can be verified? Where did you get that idea from? AFAIK, only very few projects do this - e.g. Linux Kernel requires maintainers to sign off on every patch. However, that is not common at all and most projects don't even sign even code releases!

And how would you actually imagine the "free of malware" verification being done with the thousands of packages that are in an average Linux distro? A good example of this was the NSA weakened RNG that would up in pretty much every single Linux distribution. Or bugs like Hearbleed - the only difference between a bug and a malware is that the latter was created intentionally. Technically there is little difference and the impact can be very much the same.

So no, cryptographically signed Linux repositories are certainly not immune to malware. There has been modified code distributed through these in the past - usually because the upstream source code repository got hacked and modified code inserted there.

The only thing the Linux signed packages ensure is that the package that ends up on your machine is the same as the one released/uploaded by the repository maintainer. Nothing else. That protects only against stuff like the various crapware being bundled in the installers. If there is a hidden malware or a nasty bug in the actual code, you are screwed equally well. That it doesn't happen so often with Linux is mainly because Linux is not an interesting target for this type of criminals and scammers yet, not because of some impenetrable security.

So get off your high horse, please. You have no clue.

If it is just for fun, go ahead and play with Rust. You can write C-compatible libraries with it no problem.

If it is for work, however ... Stay with your C.

Rust is nice and everything, but the ecosystem is incredibly small. There are few libraries for it, many are already unmaintained and/or not working. Also the tooling (IDEs, compiler, the cargo build tool, etc.) are fairly immature. I have been looking at it recently with the goal of writing some extension modules for Node.js & .NET, but I went back to regular C for this reason.

They have been at this for a while. AVG was autoinstalling extensions into all Windows browsers that automatically redirect your browsing through an AVG proxy (supposedly to keep you safe from viruses, ehm) for a long time. So this was only a matter of time.

BTW, AVG is not really a Czech company anymore. They have moved to the US and in the Czech republic is only their R&D centre now (Czech programmers cost 1/10th of what an US one would).

MPEG LA sues?

Media codecs are literally a patent minefield and even the likes of Microsoft or Google will have tough time breaking through the established monopolies.

I suggest that you broaden your horizon before you go ranting. You wouldn't make a fool of yourself.

First, that card doesn't work well with *any* Linux drivers, open source or not. Even their Catalyst driver is horrible in Linux.

Second, OpenGL in Linux is much more important for the professionals than gamers - large portion of virtual reality image generators (machines that render the landscapes, vehicles etc. depending on the instructions from the simulation system) used by all sorts of simulators (military, flight, driving, etc.) run Linux, because it is much easier to develop for, to keep it stable and the latest bells and whistles are not required.

Unfortunately, thanks to the boneheaded AMD management that had only a *single* developer working on Linux drivers (it used to be that way, maybe it has changed since then) and their poor OpenGL performance, driver stability (and bugs!) this is pretty much an Nvidia market now.
The same story for CAD and 3D modelling in Linux - again an Nvidia market.

So saying that this is somehow acceptable, because you are not playing games is really not helpful.

I don't have a problem with market research, but then please mark it as such. This is just dishonest and it does a disservice to everyone else by giving the impression to the general public that an actual product can be made for that ridiculous budget and timeline. Then campaigns with genuine products and realistic budgets will never get financed because people take this sort of thing as standard and realistic. At least these guys have some real prototypes and aren't just selling hot air there.

Also, doing a "market research" Kickstarter as a mean to convince VCs and/or angel investors to give you funds is pretty much a suicidal gamble - now you have 20k people who have put down their money for your gizmo and you still have no real funding to produce it. And you may not be able to get it - 20k people wanting a $200 gizmo is not that much interesting from the investment point of view by itself (that's just $4million) and it is pretty much the worst project size possible when it comes to manufacturing - too big to build in a garage and not big enough to actually give you access to the manufacturing facilities you will need. Also, few projects reach that sort of size on Kickstarter, most get much less. So unless it is something really groundbreaking, truly visionary that will make the VCs go gaga and pull out the checkbooks, you will have trouble attracting investment (heck,it is a stupid touchpad like the one Apple sells already ...). However, you are stuck with the commitment to build and ship those 20k units already ...

I more inclined to say that these people are an idealistic startup trying to bring their first project to the market, with no real past experience doing so. The completely BS time line shows that as well - they budgeted one month only for tooling and production - just the injection molding tooling production takes several weeks for every iteration (and costs thousands of $$$ a pop) and it is pretty much granted they will not get it right the first time.

So my bet is that this will ship a year or two late, over budget and probably drive the company to bancruptcy in the process.

More like the gizmo will never get made unless they have money from elsewhere and are using Kickstarter only as a marketing campaign. The $60k they are asking for won't cover even the materials. Just the mandatory FCC/CE/UL certifications will take a third of their budget, assuming that they actually pass on the first try.

This article gives a good breakdown of how much it does actually cost to build and ship a hardware product:
https://medium.com/bolt-blog/w...

Yeah, right. So it only took a decade to get serious OpenSSL bugs discovered and fixed - despite the project being open from the start. And that is most likely an order of magnitude smaller project than something like even moderately complex CPU core, written in a language that many more people are familiar with.

Yes, if it wasn't open, the bugs probably wouldn't have been found, but that's speculation - we simply will never know. If you hope to find a "backdoor" (which could be simply so subtle as intentionally weakening some crypto support instructions or random number generator if some flags are set) in a ton of Verilog/VHDL code where you need to understand both the hardware *and* the crypto, you are seriously delusional. Even the vendors themselves have only a fairly small team of people that actually understands this type of code. It is so ultra specialized niche. You will probably not see the weakness even if you were looking straight at it unless you are a specialist in exactly this domain and familiar with the implementation.

Anyhow, it is a moot point - the mainstream CPUs are never going to be "open sourced", because it is the core intellectual property of these companies.