> If the citizens demand access to those services, or find it offensive that their privacy and security is being violated and circumvented, they will take action.
Hah, right. They'll just file a complaint to their ombudsman and the Congress will take care of it.
No, this is Kazakhstan, not California. If citizens band up and demand something that the government is against, the police will crack down on their homes, arrest 15,000 people at random out of which only 10,000 or so will return to their homes (not necessarily alive), and the remaining 5,000 will rot in jail for high treason. And if they keep getting wise ideas, they'll send in the army.
When studying power consumption for this type of devices, it's extremely common to measure the current being drawn, rather than to put out values in watts.
For one thing, it's the current that you usually measure in these cases anyway. For the other, power consumption in watts is not what you generally want to know when you design a battery-powered circuit. And, last but not least, it's more useful to have a figure in (m)A than (m)W when batteries are rated in mAh.
It's not correct terminology, mind you, but then neither is that of energy in your energy bill, so I guess this can be forgiven.
Fairly important. Linear power supplies are pretty large and put out a lot of heat. It was commonplace back then for most appliances, including computers, to have a linear power supply. A switching-mode PSU was an improvement over the status quo in general.
> and was incorporating it really as simple as copying a well-known design?
Other hobby computers of the day used inefficient power supplies. The Apple ][ was the first computer ever to use a plastic case. The heat buildup using even my own power supply design (inefficient type) would have been too great. Steve tapped an Atari engineer, Rod Holt, to design a switching power supply that was much more efficient and generated less heat. Rod also keyed us into the fact that the plastic case wouldn't conduct heat well. At this point in time we took pride in being the first computer to use a switching power supply. Steve was proud of the fact that we didn't need a fan and seems to hold to that ideal to this day.
So:
* Holt designed a switching power supply which employed a patented addition to an otherwise well-known topology (it's a flyback power supply).
* Computers nowadays "rip off" the same design that Holt ripped off, they all use flyback PSUs.
* I doubt that the Apple II was really the first computer to use a switching-mode power supply, but linear supplies were pretty common among hobby computers back then. The Commodore 64 had one, for instance.
The downvoted comment about Jobs being an ignorant liar is probably spot-on.
This is a pretty interesting article! I raised more than my fair share of eyebrows by telling people I'm not really surprised with this kind of complexity (note: I'm an EE by formation, I took a frickin' two-semester course on power supplies) but that it doesn't fully justify the price difference.
Also, Jobs was a blatant liar :-). The SMPS in any modern computer is based on a standard topology that Rod Holt -- though a brilliant engineer in his own right -- didn't invent. I don't remember the specific details, but it's based on a flyback design that was certainly well-known at the time.
Basically, I think OpenBSD is a good operating system. It has a clean architecture, great code quality, and I am fond of its engineering principles.
I don't think it's Good (TM) -- there are things that other operating systems do better, and I don't think its engineering principles apply everywhere.
I admire its design, but I don't try to emulate it in any system I build.
Unfortunately, while this is true in the server/desktop world, this isn't true for embedded systems.
Hardware that can reliably run OpenBSD tends to be in the more expensive space -- x86 or PowerPC based. There are exceptions, and OpenBSD supports them (see e.g. http://www.openbsd.org/armish.html , http://www.openbsd.org/octeon.html), but these are exceptional cases where you have some documentation of reasonable quality released by the manufacturer (or outright support for porting from the manufacturer), open-ish specifications and so on.
In the IoT (read: severely price-constrained) space, you don't get to work with this kind of hardware.
To give you just one example, most cheap router SoCs are based on a MIPS core with a bunch of peripherals around (basically they're a very glorified microcontroller). Porting OpenBSD on one of these requires:
* Supporting the MIPS core. This is ok at the moment, MIPS CPUs are supported.
* Drivers for the peripherals (which include e.g. the wifi radio). This is very hard at the moment. Most manufacturers don't open source their drivers. You get a binary blob and a wrapper module, a la what nVidia does, and the specs are closed, supposedly in order to protect "intellectual property".
* And a bunch of boilerplate information, like the device tree, because these systems don't have a BIOS. There's no standard regarding this aspect, which is why even compiling Linux for these platforms is pretty painful. You generally need the manufacturer's SDK, which varies in quality, albeit after a while that gets adapted into a set of patches that get integrated in a distribution like OpenWRT or Yocto. If you're really lucky, the manufacturer might offer a Yocto or Buildroot-based distribution. If not, you get a bunch of build scripts developed in-house, with hardcoded paths and comments written in Chinese.
You do get to choose the specs, but you're still constrained to what manufacturers offer you. The cheapest available things run only Linux and maybe, if they're based on a legacy, but important product, they'll run VxWorks. But you're typically confined to what the manufacturer gives you, and the manufacturer usually gives you Linux. On 90% of the hardware popular in the IoT community, even that Linux barely works. The amount of hackery (in the pejorative sense), duct tape and outright crap code I've seen in manufacturer-provided kernelspace code is horrific. E.g. there's at least one fairly popular SoC, used in a lot (tens of thousands, if not hundreds of thousands or even million) consumer-grade routers in whose drivers I've seen synchronization based on sleep()-ing, writing to hardcoded memory addresses and so on. Yes, in kernelspace code. You don't want to see userspace code.
Thing is, most IoT companies don't want to bother with this anyway. They want something that runs an OS their development team in SE Asia or Eastern Europe (full disclosure: I'm in Eastern Europe) already knows, and they don't really care about kernelspace or userspace code because, preferably, their development team will program it in PHP and JavaScript, since three of them cost less than one C programmer who will stare at the code and quizzically mumble "how the fuck does this even boot?"
(This also accounts for the can of worms that IoT security is. A security-minded programmer would need less than a week to find several disastrous security-related bugs in the SDK of basically every popular-ish platform.)
tl;dr IoT is built on cheap, low-quality hardware where you get whatever the manufacturer gives you, and the companies are OK with this because really, they just want a box that runs a web server.
That's also true. Things weren't always like that when it comes to large organizations involved in FOSS development, but one would hope lessons are learned :-)
> Now, Canonical keeping to themselves has a very crucial advantage: they leave everyone else alone. They stay in their corner, they don't bother, they don't intervene
I certainly get why it would be in their interest to not have much collaboration. But if that's a problem for them, they should not have based their business around GPLd products. All these problems could very easily go away if Ubuntu were a FreeBSD distribution, not a Linux one.
This "stay in their corner, don't bother, don't intervene" does bother developers who increasingly have to code for Windows, OS X, Linux and, separately, Ubuntu. It's very unpleasant, and they're getting a lot of hate because users are suffering just because Canonical's business plan was shit.
I don't necessarily agree with how mjg59 chooses to resolve his issues, but it's hard not to get the impression that he's a little right about this. The problem is precisely this:
> With Ubuntu and any other software, you get the source and it is up to you to deal with the replacement of any trademark strings.
(Emphasis mine)
That's not true of any other software!
I'm not sure how things are for RHEL, but I imagine they're basically similar to Fedora. Fedora doesn't fuzzily require you to "remove and replace all trademarks". It explicitly requires you to remove the branding -- i.e. repository information, change logs and logos. They even provide a nice list of what you have to remove. Everything that you must replace is in three packages.
Now, I'd normally just suspect mjg59 of bitterness, were it not for Canonical's PR dance around the issue.
The accusation is clear: mjg59 thinks that Canonical is intentionally keeping the wording vague so that they can have a word to say in who is developing products based on Ubuntu. Anyone who wants to use something based on Ubuntu has to ask for approval. Otherwise you might end up in court because you didn't remove "Removed spurious call to foo_frobnicate() to fix crashes on Xubuntu" from an upstream changelog.
Canonical has been handing out these approvals for free so far, but I don't think any requests came from current or future competitors. There's no reason to believe that Canonical would be as eager to approve a direct Ubuntu Phone competitor.
Yes yes, it's in their interest to not be as eager, but if this was such a big problem, they should have thought twice before basing their business around a bunch of GPLd products.
It's hard to suspect Canonical of good intentions when every single answer they handed out managed to answer another question. The dialog so far has basically been:
Q: Oh hi guys, look... I'd like to make an Ubuntu derivative, can you tell me what I have to remove?
A: All trademarks.
Q: What do you mean by all trademarks?
A: Or you can ask us for approval instead.
Q: I get it, but I'd rather just remove all trademarks... what exactly do you mean by that? Do I have to remove e.g. mentions of Ubuntu from an upstream changelog, or the @ubuntu.com e-mail address of a contributor listed in an about dialog or a CONTRIBUTORS file?
A: Look, we get this is important, but we have to make sure Evil Hackers don't impersonate Ubuntu so we have to ask you to either remove all trademarks, or ask us for approval.
Q: But I'm not an evil hacker!
A: Then we'll approve your request.
Q: BUT I DON'T WANT TO ASK YOU, I JUST WANT TO KNOW WHAT TO REMOVE!
A: Look, we get this is important, but we have to make sure Evil Hackers don't impersonate Ubuntu so we have to ask you to either remove all trademarks, or ask us for approval.
It kind of gets in an infinite loop at this point.
Canonical could clarify the wording without opening themselves up to Evil Hackers. Their unwillingness to do so is (somewhat insultingly) veiled in arguments that are about as childish as they're trying to imply mjg59's are. It's hard to suspect them of good intentions under these conditions.
> Then came the new GNOME 3 and the particular way that GNOME development works. It was not workable to offer to the users a stable and distinct user experience. So, Unity was created and all hell broke loose.
I decided to take Ubuntu 15.04 out for a ride a few months ago. I haven't really used Ubuntu since 7.something (but I liked 4.10 a lot), but I did occasionally work with it (e.g. helping out colleagues who used it).
I desperately tried to like Unity, but nope: its development seems to be done pretty much the same way that Gnome development is done. A lot of effort goes into creating a distinct experience. Very little seems to go towards listening to users, and options are basically non-existant.
Changing the GTK theme, for instance, is no longer easy (you need unity-tweak-tool). Changing the buttons on the titlebar is outright impossible because now they're hardcoded.
This is... very much against the spirit of people who were involved in the open source movement a while ago. A lot of us switched to Linux because we wanted more control over our systems.
Free software that locks down your options is... missing the point a little.
Indeed, it seems that there is hardly any room left for mere programmers in this industry :-).