According to wikipedia, that had software problems that ended up killing people What's that got to do with UI changes and user experience?
The original post was about bad user interfaces causing harm to people. Changes breaking the user experience was only one of the issues.
In Therac's case the bug WAS primarily in the user interface:
- Due to a race condition, if a button happened to be pressed at the wrong moment and the menu filled out in a particular order, the device would configure the electron beam for x-ray generation rather than electron beam generation (high electron beam current, no scanning) but not position the target, flattening filter, collimator, or ion-chamber x-ray sensor in the beamway, resulting in a configuration that irradiated the patient with beta radiation, rather than x-rays, at 100x a normal dose.)
- The machine DID detect that there was a problem. But it reported it as "MALFUNCTION nn" - where nn was a number from 1 to 64 and not explained in the manual. If the operator entered "P" (proceed), it would then go ahead and operate in the improper mode anyhow.
Both the second part and most of the first part sound like user interface problem to me.
Someone started uploading all the HackingTeam source code to GitHub... There are also some signing keys for kernel drivers in here.
IMHO:
Anyone with a project hosted on git hub should pull a backup copy NOW!
Hosting this leak on git hub could lead to moves by authorities to contain it - which could have the side effect of making GitHub and/or some projects on it unavailable - temporarily or permanently.
... will this help bona fide security researchers with their work on fighting exploits on all platforms... ?
I wonder if this will also help people trying to write open software for closed devices? Signing keys, driver sources with spyware installed,... Not only does it expose the malware bypassing the user's security, it may also expose the internal details of how the devices are driven and/or how to compromise the malware's and devices' anti-user "security".
(I have often wondered how many of the closed-driver devices have the code closed just for business reasons and how many are closed because that's where the spyware has been installed and they can't let the source out - even sanitized - because that would lead to the spyware's exposure.)
The goal is to intimidate the makers of such designs. Arrest first and ask questions later, when such designs get out.
It's also to make it harder for "the common man" to arm himself - in case a Schelling Point is reached and a LOT of people suddenly decide that they need to arm themselves against the government or its puppeteers. By slowing them down, and reducing the number and quality of designs available, the powers that be have more time to react and try to divide and reconquer.
Of course intimidating designers is a big part of that.
This is not the first time they did this. In fact it has quite an interesting history in cryptography that was classified as a munition for just this reason.
Which is why OpenBSD is hosted from outside the US. (It's NOT just that Theo happens to live in Canada.)
I have similar issues:
- Towing several tons (travel trailer or 23 foot trailerable-with-extreme-trailer deep-keel coastal-water-ocean-capable sailboat) up and down mountains and cross-country.
- Going to/from the ranch - over 250 miles one way (over the Altamont grade, across the central valley, and through a pass in the Sierras) - with the last 0.7 miles sometimes hubcap-deep mud.
- Carrying ranch groceries for several months and/or other supplies or equipment from the nearest supermarket etc. - 27 miles away. and so on.
- Off-roading to visit ghost towns and other historic sites in the Nevada Desert - where "running out of gas" - in the absence of cell phone service - might mean your skeletons are discovered in a couple years.
On the other hand, for trips about 3/4 of the year and NOT towing, a plug-in hybrid or an all-electric vehicle with sufficient range, serious regenerative braking, and adequate cargo capacity for two week's groceries and luggage for two, would be ideal. Charge it up at each end (off a windmill/solar at the Nevada end) to start full, use regenerative braking on the downslopes to power across the valley or up the next up slope. For a hybrid: Top off the batteries while cruising the central valley and use batteries plus engine to avoid being a creeping traffic hazard on the mountain roads.
My cycle would be almost identical to a Silicon Valley worker who mostly commutes 25 miles each way and occasionally vacations at the Lake Tahoe ski resorts or Reno or camps in the Sierras. A single vehicle that could do both - rather than needing two vehicles to accommodate the use pattern - would be ideal.
Sure, no problem. If you dislike systemd that much, it certainly makes sense to move to a different software platform.
I don't particularly dislike systemd per se. I do observe the controversy around it, and the image of it and its project, painted by its opponents (some of whom have enough creds that it's unlikely that they're talking through their hats), indicates that the claimed issues are likely to be real problems, and this may be a tipping point for Linux adoption and user choice among distributions or OSes.
Your Snowden argument isn't particularly applicable in this instance, as you have access to the full source code for systemd. If you're not comfortable looking through C code, then any init system would be a problem for you.... If you think that porting your laptop, home servers and desktops to a completely different operating system is less effort than learning how systemd works, then I can only conclude you haven't tried to learn how systemd works. Or you've severely underestimated the work involved in moving to another OS.
I did my first Linux drivers (a PROM burner and a Selectric-with-selonoids printer) on my personal Altos ACS 68000 running System III, wrote a driver for a block-structured tape drive for AUX - working from my own decompilation of their SCSI disk driver (since the sources weren't available to me initially), ported and augmented a mainframe RAID controller from SvR3 to SvR4, and so on, for nearly three decades, through hacking DeviceTree on my current project. I don't think C has many problems left for me, nor does moving to yet another UNIX environment - especially to one that is still organized in the old, familiar, fashion. B-)
As for trying to learn how systemd works, that's not the proper question. Instead, I ask what is so great about it that I should spend the time to do so, distracting me from my other work, and how doing this would meet my goals (especially the undertand-the-security-issues goal), as compared to moving to a well-supported, time-proven, high-reliability, security-conscious alternative (which is also under a license that is less of a sell to the PHBs when building it into a shippable product.)
Snowden's revealations show that the NSA, and others like them are adept, at taking advantage of problems in obscure corners of systems and using that obscurity to avoid detection. The defence against this is simplicity and clarity, avoiding the complexity that creates subtle bugs and hides them by burying them in distractions. Bigger haystacks hide more needles.
The configuration for systemd isn't buried. It's there for all to see and change, in plain text. Logging in binary form is _optional_. You can choose to direct logged messages to syslog, or use both syslog and binary, to have the "best of both worlds", albeit with the best of disk usage.
Unfortunately, I don't get to make that choice myself. It's made by the distribution maintainers. My choice is to accept it, open the can of worms and redo the work of entire teams (and hope their software updates don't break things faster than I fix them), or pick another distribution or OS.
Again, why should I put myself on such a treadmill of unending extra work? If I could trust the maintainers to mostly make the right choices I could go along - with no more than an audit and perhaps an occasional tweak. But if they were making what I consider the right choices, I wouldn't expect to see such a debacle.
Entangling diverse processes into an interlocking mass is what operating systems are all about!;)
No, it's not. The job of an operating system is to KEEP them from becoming an interlocking mass, while letting them become an interacting system to only the extent appropriate. It isolates them in their own boxes, protects them from each other, and facilitates their access to resources and ONLY their LEGITIMATE interaction wherever appropriate and/or necessary. The job is to Keep It Simple while letting it work.
Your phrasing, and making a joke of this issue, is symptomatic of what is alleged to be wrong with systemd and the engineering behind it.
At a large scale, the internet was designed to route around individual problems such as this. Can't this same principle be applied on a smaller scale?
Yes, it can. Just dig a whole bunch MORE trenches around the country at enormous cost.
The SONET fiber networks were designed to be primarily intersecting rings. Most sites have fiber going in opposite directions (with a few having more than two fibers going off in more than two directions so it's not just ONE big, convoluted, ring.) This is built right into the signaling architecture: Bandwitdth slots are pre-assigned in both directions around the ring. Cut ONE fiber run and the signals that would have crossed the break are folded back at the boxes at each end of the break, run around the ring the other way, and get to where they're going after taking the long route. The switching is automatic and takes place in miliseconds. The ring approach means that the expensive cable runs are about a short and as separated as it's possible to make them.
But cut the ring in TWO places and it partitions into two, unconnected, networks. To get from one to the other you have to hope there's another run between the two pieces, and there's enough switching where they join to reroute the traffic.
IP WANs have, in some portions, also adopted the ring topology as they move to fiber, rather than sticking to the historic "network of intersecting trees" approach everywhere. That's partly because much of the long haul is done on formerly "dark fiber" laid down in bundles with the SONET rings from the great fiber buildout (or is carried in assigned bandwidth slots on the SONET networks themselves), partly because the same economics of achieving redundancy while minimizing costly digging apply to high-bandwidth networking regardless of the format of the traffic, and partly because routers that KNOW they're on a ring can reroute everything quickly when a fiber run fails, rather than rediscovering what's still alive and recomputing all the routing tables.
= = = = =
Personal note: Back when Pacific Bell was stringing its fibers around the San Francisco Bay Area, I was living in Palo Alto. They did their backbone as two rings. There was only one section, perhaps a mile long, where BOTH rings ran along the same route. It happened to go right past my house, with the big, many-manhole repeater vault right next to the house. (I used to daydream of running my own fiber the few feet into the vault. B-) The best I had available, in those pre-DSL days, were dialup with Telebit PEP modems (18-23 k half-duplex) and base-rate (128k) ISDN.)
Anyway, I digress. Advantages of systemd are: [long list]
Those are all very nice things to have.
Unfortunately, for my needs, simplicity and understandability are far more important than a fast boot and feature-rich management of the runtime environment. I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
If the improved functionality is at the cost of burying the configuration and logging in non-human-readable form and entangling diverse processes into an interlocking mass under a complex and ever growing manager, the shark has been jumped.
Though Linux has been becoming (MUCH!) more usable with time, its configuration has been buried progressively more deeply under more and more "convenient and simplifying", but non-transparent, configuration management tools. Systemd is the continuation of the trend. But it is also a quantum leap, rather than another thin slice off the salami. So it has apparently created the "Shelling Point", where a lot of frogs simultaneously figure out that NOW is the time to jump out of the pot.
It's been a great ride. It had the potential to be even greater. But I think this is where it took the wrong turn and it's time for me to get serious about switching.
There's good reason to switch to NetBSD at work, on the product. (The code supporting the secret sauce is on the user side of the API and is Posix compatible, so it should be no big problem.) Porting my laptop, home servers, and desktops to OpenBSD now looks like it's worth the effort - and less effort than trying to learn, and keep abreast of, the internals of systemd.
Call me if somebody comes up with a way to obtain the key benefits of systemd in a simple and transparent manner, rather than creating an opaque mass reminiscent of Tron's Master Control Program. (Unfortunately, the downsides of systemd's approach seem to be built into its fundamental structure, so I don't expect it to evolve into something suitable, even if it's forked.)
One (OpenBSD) is for having as secure a desktop/server/embedded platform as the maintainers can manage - important in this post-Snowden era (as it was, all unknown, in the era preceding Snowden B-b). It is based outside the US so it can incorporate strong encryption without coming afoul of US export controls.
One (NetBSD) is for developing network internals software and networking platforms (typically ported, when possible and not part of a proprietary product, to the others and other OSes.)
One (FreeBSD), now that its original purpose of getting the code disentangled from proprietary accomplished and the other two projects forked from it, is for making an open unix-like system run on the widest range of hardware platforms and devices possible.
Unless you're using your machine for building networking equipment or it's a new hardware platform under development, the choice seems clear.
According to the first amendment, the government of the United States can't stop you.
If the denizens of the largest religion of the Unitied States (Progressivism), or at least their media spokespreachers, decide to gang-shun you, there's still the other half of the population to interact with.
Fortunately, techies usually have to deal with real-world more than social issues. Unfortunately, PHBs have control of the money and have to interact with the fanatics. Fortunately, techies are noted for not being skilled on social fads and are given much slack. Unfortunately, that slack sometimes comes with a hook: The PHB tells his techies not to be a "lightning rod" and say/post things, in a way traceable to a particular employee of The Company, that might bring down the wrath of the pressure groups, make it look like his "herd of cats" really IS crazy and repell funders and customers, or otherwise make his job harder than it already is.
Which (mainly the "crazy cats" case) is why I started posting anything that MIGHT be controversial under pseudonyms. And a reference to the PHB's order is the origin of the slashdot pseudonym "Ungrounded Lightning Rod" (since slashed down to "Ungrounded Lightning" by changes to the slashcode that limited pseudonym size). And why, now that "ULR" has a large and valuable reputation (and though that reputation might help with job searches) I STILL don't out the corresponding "True Name" on any electronic medium.
(So now you know.)
In Linus' case, I doubt that even a gang-shun by the Politically Correct would have an impact, on his finances, his social standing, or the adoption of his work or technical ideas.
(Can you imagine, for instance, the luddites , or even Microsoft's PR department, trying to get people to avoid Linux and switch to Windows or MacOS, or avoid git and switch to Clearcase, Bitkeeper,... because Linus once said "... run away, screaming like little girl" and therefore must be a Sexist Pig? Especially, can you imagine ANY tech company using THAT slander and thus inviting that kind of scrutiny of their OWN people? B-) )
So have faith. Either he's right, and systemd will not turn out to be that bad, or his faith in systemd will end in tears, and then, he'll sit down and write a new startup management system that will kick everybody else's collective asses!
Or maybe somebody ELSE will write a kick-ass init system, and Linus will say "Hey, that's cool!" and promote it. Or the maintainers of a major distribution will adopt it. Or those of a MINOR distribution will - and user will migrate.
Linus is great. But why does THIS have to be HIS problem? The init system may have a bit of extra-special status and privilege, but it's largely NOT the kernel's problem. Along with the system call API it is THE boundary between the kernel guts and the user/demon/daemon firmament. It says to the kernel: "Thanks, I'll take it from here."
You don't HAVE to generate it within a fraction of a second of when it's used - that's just been convenient so far. So it's not with renewables? Fine! Store that juice!
"There's no battery technology that's even close to allowing us to take all of our energy from renewables and be able to use battery storage in order to deal not only with the 24-hour cycle but also with long periods of time where it's cloudy and you don't have sun or you don't have wind."
he's totally wrong.
For starters, there's Vanadium Redox. A flow battery (pumped electrolyte): Power limited by the size of the reaction device's electrode and membrane assembly. Energy storage limited by the size of the tanks. It's mainly used for utility-level energy storage down under (Oz or Nz, I think), because the patents are still fresh and the little startup doesn't want to license it to others. Vanadium is some substantial percentage of the Earth's crust so there's no shortage. Using the same element (in different sets of oxidation states - vanadium has (at least) 6 of 'em) for BOTH electrodes means leakage of small amounts of the element through the dilectric membrane doesn't poison the battery.
Lithum cells are already good enough to run laptops, cars, and houses, and are improving at a Moore's Law like rate. The elements are also not rare and the use of several nanotech techniques on the electrodes have drastically increased the lifetime and other useful properties. (We just had reports of yet another breakthrough within the last day or so, doubling the capacity and extending the life.) The fast-charge/discharge cells are also extremely efficient. (They have to be, because every horsepower is 3/4 kW, so even a few percent of loss would translate to enormous heat in an automotive application.) The main problem is to get companies to "pull the trigger" on deploying them - and risk their new production line being rendered obsolete before the product hits the market by NEXT month's breakthroughs.
Lead-acids need to be replaced once or twice per decade. But they have been the workhorses for off-grid since Edison's and Nikola Tesla's days, and still are today (though not for long, if Elon Musk and the five billion dollars of investments in his lithium battery plant have anything to say about it).
Nickel-Iron wet cells are a technology developed by Edison. They have more loss than lead-acids. But they literally last for centuries. If you have a moderately steady renewable source (like some combination of enough wind and a big enough windmill, enough sun and a big enough solar array, or a stream and a big enough hydro system) you'll have enough more power than you need to keep them topped off. They're just fine for covering days, or even a couple weeks, of bad generation weather, or down-for-maintenance situations. That IS what they were in at least one hydro plant I know of. (The problem is finding them: They last so long you only need to buy them ONCE, so there aren't many plants.)
That's just four FAMILIES of entirely adequate solutions. There ARE more.
So Bill is either uninformed, talking through his hat, or starting on the "embrace" stage of yet another:
- Embrace
- Extend
- Extinguish
- PROFIT!
we have a way to turn electricity directly into heat. But there is no direct way to turn heat into electricity. It has to go thru a second step of mechanical energy to spin a magnet to create electricity.
You can go from electricity directly to heat because that increases entropy. You can't go from heat to anything useful because that decreases entropy, and entropy of a closed system only increases. The best you can do is a heat engine, working off a temperature DIFFERENCE. (Some of them also work backward as heat pumps, to go from electricity to heat more effectively, by also grabbing some heat from elsewhere to include in the hot end output.)
There ARE at least two major forms of electronic heat engines - direct from temperature differences to electricity, with only charge carriers as the moving parts: Thermoelectrics (thermocouples, peltier junctions, and thermopiles of them) and thermionics (both heat-driven vacuum diode generators and a FET-like semiconductor analog of them). Both are discussed in other responses to the parent post.
TEs are ridiculously inefficient and aren't looking to be much better anytime soon
Because thermoelectric effect devices leak heat big time.
However there's also thermionics. The vacuum-tube version is currently inefficient - about as inefficient as slightly behind-the-curve solar cells - due to space charge accumulation discouraging current, but I've seen reports of a semiconductor close analog of it (as an FET is a semiconductor close analog of a vacuum triode) that IS efficient, encouraging the space charge to propagate through the drift region by doping tricks (that I don't recall offhand). The semiconductor version beats the problems that plague thermoelectrics because the only charge carriers crossing the temperature gradient are the ones doing so in an efficient manner, so the bulk of the thermal leakage is mechanical rather than electrical, and the drift region can be long enough to keep that fraction down.
I got the impression from the (sketchy) article that repeater AMPLIFIERS were still needed but repeater REGENERATORS were not.
Then again - another part of the article makes it look like an additional result was that they could boost this less-subject-to-degradation-by-nonlinear-distortions signal at the start until the fibre itself was acting non-linearly, in order to get a signal strong enough to survive a much longer hop.
So it's not clear to me whether the distance was achieved by:
- long hops enabled by strong signals, and NO amplifiers
- longer propagation without regenaration using JUST amplifers
- a combination of the two: Both getting long total length without regeneration AND being able to use stronger signals and thus use larger space between the amplifier-type repeaters.
Since the diameter of the earth is 7 926.3352 miles, this could conceivably remove any need for repeaters.
I got the impression from the (sketchy) article that repeater AMPLIFIERS were still needed but repeater REGENERATORS were not.
I.e. you still needed to boost the strength of the signal to make up for the losses. But the progressive degradation of the quality of the signal - with data from different frequency bands bleeding into other bands (especially in the amplifiers themselves) due to nonlinear "mixing" processes - had been headed off, by synchronizing the frequencies of all the carriers to exact multiples of a common basic difference-between-the-carriers frequency.
This apparently sets up a situation where the distortion products of each carrier's interaction with nonlinear processes cancel out with respect to trying to recover the signals on another carrier - much the way the modulation products do in OFDM modulation schemes. In OFDM it allows you to make essentially total use of the bandwidth. In this system it lets you use simple, cheap, amplifiers to get your signal boost, rather than ending the fibre before things get too intertwingled, demodulating all the signals back to data streams and recovered clocking, then generating a fresh set of modulated light streams for the next hop - MUCH more expensive and power hungry.
... government regulators couldn't possibly find financial irregularities by grabbing you documents from the cloud service provider,...
The courts said you have no expectation of privacy one you put your data in the hands of a third party. Great! Let's convince all those "evil corporations" to store all their data in the cloud. Then the government can go after them any time they want. B-b
IMHO Romney could have won it if his supporters hadn't cheated the Ron Paul supporters so blatantly, publicly, and sometimes violently, that they alienated, not just them, but many of the other factions of the Republican Party as well.
Many Paulites (and others) will never again vote for Romney, or any candidate supported by the Neocon machine (alias the "GOP Power Structure) or at least by a number of major figures who were involved in the corruption. The thinking is "If that's the way they treat their own party members in a primary/caucus, they can NOT be allowed to control the mechanisms of the Federal Government."
There are five states that Romney lost by substantially less than the number of people who actually voted for Paul in the primaries/caucuses, with an aggregate number of electoral votes to give him the win. If you assume that these Paul people would have voted for Romney if he'd won the nomination without massive cheating (as he probably would have) and instead sat it out (or enough other Republicans behaved that way to make up for Paulites who didn't) it would have been President Romney.
On the other hand, if Paul had managed to win the primary he'd likely have trounced Obama. He can pull support from much of the Democratic Party's base and enough of the typical Republican voters to make up for any that might have sat out HIS run.
Because "High Fructose Corn Syrup" rolls off the tongue slightly better than "a 50%:50% ±10% homogeneous mixture of fructose and glucose with >0.5% residual corn proteins and cellulose."
Not to mention bacteria enzymes.
My personal problem with HFCS is that I'm allergic to corn, and food-grade purification processes don't clean out enough of what I'm allergic to for ANY corn-sourced food ingredient to be safe for me. (As I understand it, antibodies are THE most sensitive detectors of particular molecules / molecular sites known to man, and it only takes four molecules to trigger an allergic reaction.) Fry it (ALL!) brown and it's safe, else forget it.
But I hear that HFCS is an obesity issue because it doesn't trip the appetite regulation as strongly as sucrose, so people tend to eat more of it.
$100+/bulb is VERY pricey. (Lots of LED bulbs already have TI radio/processor chips - usually the otherwise-identical ones with zigbee rather than BLE - for substantially less.
Adding a battery and related circuitry to do operate-over-power-failure is nice but not that much of a cost. Adding a speaker/microphone, a suitable processor to drive it, and some network and security software, may justify a substantial boost. But software amortizes to "almost free" over large numbers of units. So it seems to me the price point is too high. I expect this will die from competition.
The CPU is also fast because it's made of small components close together. It's built using current large-chip fabrication technology. re-optimized for low leakage, of course.
When a substantial fraction of the target applications are intended to run for years on a fractional amp-hour lithium button or harvested ambient energy, power saving is critical.
If the CPU in the IoT Device is powerful enough to make offloading actually worthwhile, isn't that CPU way overkill for the IoT Device's primary function?
Not at all. The CPU is fast to reduce latency. This not only meets response targets, but it also means the CPU can shut down after a very short time, saving power.
This is especially important on battery powered devices. If the CPU is off except for a couple of milliseconds every few seconds, a battery can last for years.
The CPU is also fast because it's made of small components close together. It's built using current large-chip fabrication technology. Making it physically small means many chips per die, which means low cost per chip. If that makes it fast, so much the better .
As long as you're not using extra power to increase the speed further, there's no problem with a processor being "too fast". That just means it can go to sleep sooner. In fact, slowing it down can be expensive: Slower means not only that the power is on longer, but it also usually means bigger components which require more electrons to change their voltage. The more electrons delivered by the battery, the more if it is used up. Oops!
Granted that the processors are powerful and cheap, and have a lot of computation potential. But there are other downsides to trying to use IoT devices for a computing resource.
One is that the volatile memory, which uses scarce power just holding its state is very small, and the permanent memory, though it may be moderately large, is flash: VERY slow, VERY power consuming to do a write (and the processor stops while you're writing flash, screwing things up for its primary purpose).
Much of the current generation IoT devices run on either the Texas Instruments CC2541 (8051 processor, 8kB RAM, 256kB flash) and its relatives, or the Nordic nRF51822 (32-bit ARM® Cortexâ M0 CPU, 32kB/16kB RAM, 256kB/128kB flash) and its family, and the next generation is an incremental improvement rather than a breakthrough. You can do a lot in a quarter megabyte of code space (if you're willing to work at it a bit like we did in the early days of computing). But there's not a lot of elbow room there.
The tiny memories mean you don't have a lot of resource to throw at operating systems and extra work. In fact, though the communication stacks are pretty substantial (and use up a LOT of the flash!), the OSes are pretty rudimentary: Mostly custom event loop abstraction layers, talking to applications that are mostly event and callback handlers. Development environments encourage custom loads that don't have any pieces of libraries or system services that aren't actually used by the applications.
Another downside is the lack of bandwidth for communicating between them. (Bluetooth Low Energy, for example, runs at one megaBIT per second, has a lot of overhead and tiny packets, and divides three "advertising" (connection establishment) channels, in the cracks between 2.4GHz WiFI chnnels, among ALL the machines in radio "earshot".) Maybe they can do a lot of deep thought - but getting the work to, and the results from, all those little guys will be a bottleneck.
Maybe Moore's Law and the economic advantage of saving programmer time may make this change in the future. But I'm not holding my breath waiting for "smart" lightbulbs to have large, standardized, OSes making that "wasted" CPU power available to parasitic worms.
Slashdot Mirror
According to wikipedia, that had software problems that ended up killing people What's that got to do with UI changes and user experience?
The original post was about bad user interfaces causing harm to people. Changes breaking the user experience was only one of the issues.
In Therac's case the bug WAS primarily in the user interface:
- Due to a race condition, if a button happened to be pressed at the wrong moment and the menu filled out in a particular order, the device would configure the electron beam for x-ray generation rather than electron beam generation (high electron beam current, no scanning) but not position the target, flattening filter, collimator, or ion-chamber x-ray sensor in the beamway, resulting in a configuration that irradiated the patient with beta radiation, rather than x-rays, at 100x a normal dose.)
- The machine DID detect that there was a problem. But it reported it as "MALFUNCTION nn" - where nn was a number from 1 to 64 and not explained in the manual. If the operator entered "P" (proceed), it would then go ahead and operate in the improper mode anyhow.
Both the second part and most of the first part sound like user interface problem to me.
Someone started uploading all the HackingTeam source code to GitHub ... There are also some signing keys for kernel drivers in here.
IMHO:
Anyone with a project hosted on git hub should pull a backup copy NOW!
Hosting this leak on git hub could lead to moves by authorities to contain it - which could have the side effect of making GitHub and/or some projects on it unavailable - temporarily or permanently.
Better safe than sorry.
... will this help bona fide security researchers with their work on fighting exploits on all platforms ... ?
I wonder if this will also help people trying to write open software for closed devices? Signing keys, driver sources with spyware installed, ... Not only does it expose the malware bypassing the user's security, it may also expose the internal details of how the devices are driven and/or how to compromise the malware's and devices' anti-user "security".
(I have often wondered how many of the closed-driver devices have the code closed just for business reasons and how many are closed because that's where the spyware has been installed and they can't let the source out - even sanitized - because that would lead to the spyware's exposure.)
The goal is to intimidate the makers of such designs. Arrest first and ask questions later, when such designs get out.
It's also to make it harder for "the common man" to arm himself - in case a Schelling Point is reached and a LOT of people suddenly decide that they need to arm themselves against the government or its puppeteers. By slowing them down, and reducing the number and quality of designs available, the powers that be have more time to react and try to divide and reconquer.
Of course intimidating designers is a big part of that.
This is not the first time they did this. In fact it has quite an interesting history in cryptography that was classified as a munition for just this reason.
Which is why OpenBSD is hosted from outside the US. (It's NOT just that Theo happens to live in Canada.)
I have similar issues:
- Towing several tons (travel trailer or 23 foot trailerable-with-extreme-trailer deep-keel coastal-water-ocean-capable sailboat) up and down mountains and cross-country.
- Going to/from the ranch - over 250 miles one way (over the Altamont grade, across the central valley, and through a pass in the Sierras) - with the last 0.7 miles sometimes hubcap-deep mud.
- Carrying ranch groceries for several months and/or other supplies or equipment from the nearest supermarket etc. - 27 miles away.
and so on.
- Off-roading to visit ghost towns and other historic sites in the Nevada Desert - where "running out of gas" - in the absence of cell phone service - might mean your skeletons are discovered in a couple years.
On the other hand, for trips about 3/4 of the year and NOT towing, a plug-in hybrid or an all-electric vehicle with sufficient range, serious regenerative braking, and adequate cargo capacity for two week's groceries and luggage for two, would be ideal. Charge it up at each end (off a windmill/solar at the Nevada end) to start full, use regenerative braking on the downslopes to power across the valley or up the next up slope. For a hybrid: Top off the batteries while cruising the central valley and use batteries plus engine to avoid being a creeping traffic hazard on the mountain roads.
My cycle would be almost identical to a Silicon Valley worker who mostly commutes 25 miles each way and occasionally vacations at the Lake Tahoe ski resorts or Reno or camps in the Sierras. A single vehicle that could do both - rather than needing two vehicles to accommodate the use pattern - would be ideal.
Sure, no problem. If you dislike systemd that much, it certainly makes sense to move to a different software platform.
I don't particularly dislike systemd per se. I do observe the controversy around it, and the image of it and its project, painted by its opponents (some of whom have enough creds that it's unlikely that they're talking through their hats), indicates that the claimed issues are likely to be real problems, and this may be a tipping point for Linux adoption and user choice among distributions or OSes.
Your Snowden argument isn't particularly applicable in this instance, as you have access to the full source code for systemd. If you're not comfortable looking through C code, then any init system would be a problem for you. ... If you think that porting your laptop, home servers and desktops to a completely different operating system is less effort than learning how systemd works, then I can only conclude you haven't tried to learn how systemd works. Or you've severely underestimated the work involved in moving to another OS.
I did my first Linux drivers (a PROM burner and a Selectric-with-selonoids printer) on my personal Altos ACS 68000 running System III, wrote a driver for a block-structured tape drive for AUX - working from my own decompilation of their SCSI disk driver (since the sources weren't available to me initially), ported and augmented a mainframe RAID controller from SvR3 to SvR4, and so on, for nearly three decades, through hacking DeviceTree on my current project. I don't think C has many problems left for me, nor does moving to yet another UNIX environment - especially to one that is still organized in the old, familiar, fashion. B-)
As for trying to learn how systemd works, that's not the proper question. Instead, I ask what is so great about it that I should spend the time to do so, distracting me from my other work, and how doing this would meet my goals (especially the undertand-the-security-issues goal), as compared to moving to a well-supported, time-proven, high-reliability, security-conscious alternative (which is also under a license that is less of a sell to the PHBs when building it into a shippable product.)
Snowden's revealations show that the NSA, and others like them are adept, at taking advantage of problems in obscure corners of systems and using that obscurity to avoid detection. The defence against this is simplicity and clarity, avoiding the complexity that creates subtle bugs and hides them by burying them in distractions. Bigger haystacks hide more needles.
The configuration for systemd isn't buried. It's there for all to see and change, in plain text. Logging in binary form is _optional_. You can choose to direct logged messages to syslog, or use both syslog and binary, to have the "best of both worlds", albeit with the best of disk usage.
Unfortunately, I don't get to make that choice myself. It's made by the distribution maintainers. My choice is to accept it, open the can of worms and redo the work of entire teams (and hope their software updates don't break things faster than I fix them), or pick another distribution or OS.
Again, why should I put myself on such a treadmill of unending extra work? If I could trust the maintainers to mostly make the right choices I could go along - with no more than an audit and perhaps an occasional tweak. But if they were making what I consider the right choices, I wouldn't expect to see such a debacle.
Entangling diverse processes into an interlocking mass is what operating systems are all about! ;)
No, it's not. The job of an operating system is to KEEP them from becoming an interlocking mass, while letting them become an interacting system to only the extent appropriate. It isolates them in their own boxes, protects them from each other, and facilitates their access to resources and ONLY their LEGITIMATE interaction wherever appropriate and/or necessary. The job is to Keep It Simple while letting it work.
Your phrasing, and making a joke of this issue, is symptomatic of what is alleged to be wrong with systemd and the engineering behind it.
At a large scale, the internet was designed to route around individual problems such as this.
Can't this same principle be applied on a smaller scale?
Yes, it can. Just dig a whole bunch MORE trenches around the country at enormous cost.
The SONET fiber networks were designed to be primarily intersecting rings. Most sites have fiber going in opposite directions (with a few having more than two fibers going off in more than two directions so it's not just ONE big, convoluted, ring.) This is built right into the signaling architecture: Bandwitdth slots are pre-assigned in both directions around the ring. Cut ONE fiber run and the signals that would have crossed the break are folded back at the boxes at each end of the break, run around the ring the other way, and get to where they're going after taking the long route. The switching is automatic and takes place in miliseconds. The ring approach means that the expensive cable runs are about a short and as separated as it's possible to make them.
But cut the ring in TWO places and it partitions into two, unconnected, networks. To get from one to the other you have to hope there's another run between the two pieces, and there's enough switching where they join to reroute the traffic.
IP WANs have, in some portions, also adopted the ring topology as they move to fiber, rather than sticking to the historic "network of intersecting trees" approach everywhere. That's partly because much of the long haul is done on formerly "dark fiber" laid down in bundles with the SONET rings from the great fiber buildout (or is carried in assigned bandwidth slots on the SONET networks themselves), partly because the same economics of achieving redundancy while minimizing costly digging apply to high-bandwidth networking regardless of the format of the traffic, and partly because routers that KNOW they're on a ring can reroute everything quickly when a fiber run fails, rather than rediscovering what's still alive and recomputing all the routing tables.
= = = = =
Personal note: Back when Pacific Bell was stringing its fibers around the San Francisco Bay Area, I was living in Palo Alto. They did their backbone as two rings. There was only one section, perhaps a mile long, where BOTH rings ran along the same route. It happened to go right past my house, with the big, many-manhole repeater vault right next to the house. (I used to daydream of running my own fiber the few feet into the vault. B-) The best I had available, in those pre-DSL days, were dialup with Telebit PEP modems (18-23 k half-duplex) and base-rate (128k) ISDN.)
Anyway, I digress. Advantages of systemd are: [long list]
Those are all very nice things to have.
Unfortunately, for my needs, simplicity and understandability are far more important than a fast boot and feature-rich management of the runtime environment. I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
If the improved functionality is at the cost of burying the configuration and logging in non-human-readable form and entangling diverse processes into an interlocking mass under a complex and ever growing manager, the shark has been jumped.
Though Linux has been becoming (MUCH!) more usable with time, its configuration has been buried progressively more deeply under more and more "convenient and simplifying", but non-transparent, configuration management tools. Systemd is the continuation of the trend. But it is also a quantum leap, rather than another thin slice off the salami. So it has apparently created the "Shelling Point", where a lot of frogs simultaneously figure out that NOW is the time to jump out of the pot.
It's been a great ride. It had the potential to be even greater. But I think this is where it took the wrong turn and it's time for me to get serious about switching.
There's good reason to switch to NetBSD at work, on the product. (The code supporting the secret sauce is on the user side of the API and is Posix compatible, so it should be no big problem.) Porting my laptop, home servers, and desktops to OpenBSD now looks like it's worth the effort - and less effort than trying to learn, and keep abreast of, the internals of systemd.
Call me if somebody comes up with a way to obtain the key benefits of systemd in a simple and transparent manner, rather than creating an opaque mass reminiscent of Tron's Master Control Program. (Unfortunately, the downsides of systemd's approach seem to be built into its fundamental structure, so I don't expect it to evolve into something suitable, even if it's forked.)
As I understand the three major forks:
One (OpenBSD) is for having as secure a desktop/server/embedded platform as the maintainers can manage - important in this post-Snowden era (as it was, all unknown, in the era preceding Snowden B-b). It is based outside the US so it can incorporate strong encryption without coming afoul of US export controls.
One (NetBSD) is for developing network internals software and networking platforms (typically ported, when possible and not part of a proprietary product, to the others and other OSes.)
One (FreeBSD), now that its original purpose of getting the code disentangled from proprietary accomplished and the other two projects forked from it, is for making an open unix-like system run on the widest range of hardware platforms and devices possible.
Unless you're using your machine for building networking equipment or it's a new hardware platform under development, the choice seems clear.
Are we allowed to say that out loud?
According to the first amendment, the government of the United States can't stop you.
If the denizens of the largest religion of the Unitied States (Progressivism), or at least their media spokespreachers, decide to gang-shun you, there's still the other half of the population to interact with.
Fortunately, techies usually have to deal with real-world more than social issues. Unfortunately, PHBs have control of the money and have to interact with the fanatics. Fortunately, techies are noted for not being skilled on social fads and are given much slack. Unfortunately, that slack sometimes comes with a hook: The PHB tells his techies not to be a "lightning rod" and say/post things, in a way traceable to a particular employee of The Company, that might bring down the wrath of the pressure groups, make it look like his "herd of cats" really IS crazy and repell funders and customers, or otherwise make his job harder than it already is.
Which (mainly the "crazy cats" case) is why I started posting anything that MIGHT be controversial under pseudonyms. And a reference to the PHB's order is the origin of the slashdot pseudonym "Ungrounded Lightning Rod" (since slashed down to "Ungrounded Lightning" by changes to the slashcode that limited pseudonym size). And why, now that "ULR" has a large and valuable reputation (and though that reputation might help with job searches) I STILL don't out the corresponding "True Name" on any electronic medium.
(So now you know.)
In Linus' case, I doubt that even a gang-shun by the Politically Correct would have an impact, on his finances, his social standing, or the adoption of his work or technical ideas.
(Can you imagine, for instance, the luddites , or even Microsoft's PR department, trying to get people to avoid Linux and switch to Windows or MacOS, or avoid git and switch to Clearcase, Bitkeeper, ... because Linus once said "... run away, screaming like little girl" and therefore must be a Sexist Pig? Especially, can you imagine ANY tech company using THAT slander and thus inviting that kind of scrutiny of their OWN people? B-) )
So have faith. Either he's right, and systemd will not turn out to be that bad, or his faith in systemd will end in tears, and then, he'll sit down and write a new startup management system that will kick everybody else's collective asses!
Or maybe somebody ELSE will write a kick-ass init system, and Linus will say "Hey, that's cool!" and promote it. Or the maintainers of a major distribution will adopt it. Or those of a MINOR distribution will - and user will migrate.
Linus is great. But why does THIS have to be HIS problem? The init system may have a bit of extra-special status and privilege, but it's largely NOT the kernel's problem. Along with the system call API it is THE boundary between the kernel guts and the user/demon/daemon firmament. It says to the kernel: "Thanks, I'll take it from here."
Or we build storage.
You don't HAVE to generate it within a fraction of a second of when it's used - that's just been convenient so far. So it's not with renewables? Fine! Store that juice!
When Bill Gates says:
he's totally wrong.
For starters, there's Vanadium Redox. A flow battery (pumped electrolyte): Power limited by the size of the reaction device's electrode and membrane assembly. Energy storage limited by the size of the tanks. It's mainly used for utility-level energy storage down under (Oz or Nz, I think), because the patents are still fresh and the little startup doesn't want to license it to others. Vanadium is some substantial percentage of the Earth's crust so there's no shortage. Using the same element (in different sets of oxidation states - vanadium has (at least) 6 of 'em) for BOTH electrodes means leakage of small amounts of the element through the dilectric membrane doesn't poison the battery.
Lithum cells are already good enough to run laptops, cars, and houses, and are improving at a Moore's Law like rate. The elements are also not rare and the use of several nanotech techniques on the electrodes have drastically increased the lifetime and other useful properties. (We just had reports of yet another breakthrough within the last day or so, doubling the capacity and extending the life.) The fast-charge/discharge cells are also extremely efficient. (They have to be, because every horsepower is 3/4 kW, so even a few percent of loss would translate to enormous heat in an automotive application.) The main problem is to get companies to "pull the trigger" on deploying them - and risk their new production line being rendered obsolete before the product hits the market by NEXT month's breakthroughs.
Lead-acids need to be replaced once or twice per decade. But they have been the workhorses for off-grid since Edison's and Nikola Tesla's days, and still are today (though not for long, if Elon Musk and the five billion dollars of investments in his lithium battery plant have anything to say about it).
Nickel-Iron wet cells are a technology developed by Edison. They have more loss than lead-acids. But they literally last for centuries. If you have a moderately steady renewable source (like some combination of enough wind and a big enough windmill, enough sun and a big enough solar array, or a stream and a big enough hydro system) you'll have enough more power than you need to keep them topped off. They're just fine for covering days, or even a couple weeks, of bad generation weather, or down-for-maintenance situations. That IS what they were in at least one hydro plant I know of. (The problem is finding them: They last so long you only need to buy them ONCE, so there aren't many plants.)
That's just four FAMILIES of entirely adequate solutions. There ARE more.
So Bill is either uninformed, talking through his hat, or starting on the "embrace" stage of yet another:
- Embrace
- Extend
- Extinguish
- PROFIT!
we have a way to turn electricity directly into heat. But there is no direct way to turn heat into electricity. It has to go thru a second step of mechanical energy to spin a magnet to create electricity.
You can go from electricity directly to heat because that increases entropy. You can't go from heat to anything useful because that decreases entropy, and entropy of a closed system only increases. The best you can do is a heat engine, working off a temperature DIFFERENCE. (Some of them also work backward as heat pumps, to go from electricity to heat more effectively, by also grabbing some heat from elsewhere to include in the hot end output.)
There ARE at least two major forms of electronic heat engines - direct from temperature differences to electricity, with only charge carriers as the moving parts: Thermoelectrics (thermocouples, peltier junctions, and thermopiles of them) and thermionics (both heat-driven vacuum diode generators and a FET-like semiconductor analog of them). Both are discussed in other responses to the parent post.
TEs are ridiculously inefficient and aren't looking to be much better anytime soon
Because thermoelectric effect devices leak heat big time.
However there's also thermionics. The vacuum-tube version is currently inefficient - about as inefficient as slightly behind-the-curve solar cells - due to space charge accumulation discouraging current, but I've seen reports of a semiconductor close analog of it (as an FET is a semiconductor close analog of a vacuum triode) that IS efficient, encouraging the space charge to propagate through the drift region by doping tricks (that I don't recall offhand). The semiconductor version beats the problems that plague thermoelectrics because the only charge carriers crossing the temperature gradient are the ones doing so in an efficient manner, so the bulk of the thermal leakage is mechanical rather than electrical, and the drift region can be long enough to keep that fraction down.
I got the impression from the (sketchy) article that repeater AMPLIFIERS were still needed but repeater REGENERATORS were not.
Then again - another part of the article makes it look like an additional result was that they could boost this less-subject-to-degradation-by-nonlinear-distortions signal at the start until the fibre itself was acting non-linearly, in order to get a signal strong enough to survive a much longer hop.
So it's not clear to me whether the distance was achieved by:
- long hops enabled by strong signals, and NO amplifiers
- longer propagation without regenaration using JUST amplifers
- a combination of the two: Both getting long total length without regeneration AND being able to use stronger signals and thus use larger space between the amplifier-type repeaters.
Since the diameter of the earth is 7 926.3352 miles, this could conceivably remove any need for repeaters.
I got the impression from the (sketchy) article that repeater AMPLIFIERS were still needed but repeater REGENERATORS were not.
I.e. you still needed to boost the strength of the signal to make up for the losses. But the progressive degradation of the quality of the signal - with data from different frequency bands bleeding into other bands (especially in the amplifiers themselves) due to nonlinear "mixing" processes - had been headed off, by synchronizing the frequencies of all the carriers to exact multiples of a common basic difference-between-the-carriers frequency.
This apparently sets up a situation where the distortion products of each carrier's interaction with nonlinear processes cancel out with respect to trying to recover the signals on another carrier - much the way the modulation products do in OFDM modulation schemes. In OFDM it allows you to make essentially total use of the bandwidth. In this system it lets you use simple, cheap, amplifiers to get your signal boost, rather than ending the fibre before things get too intertwingled, demodulating all the signals back to data streams and recovered clocking, then generating a fresh set of modulated light streams for the next hop - MUCH more expensive and power hungry.
... government regulators couldn't possibly find financial irregularities by grabbing you documents from the cloud service provider, ...
The courts said you have no expectation of privacy one you put your data in the hands of a third party. Great! Let's convince all those "evil corporations" to store all their data in the cloud. Then the government can go after them any time they want. B-b
IMHO Romney could have won it if his supporters hadn't cheated the Ron Paul supporters so blatantly, publicly, and sometimes violently, that they alienated, not just them, but many of the other factions of the Republican Party as well.
Many Paulites (and others) will never again vote for Romney, or any candidate supported by the Neocon machine (alias the "GOP Power Structure) or at least by a number of major figures who were involved in the corruption. The thinking is "If that's the way they treat their own party members in a primary/caucus, they can NOT be allowed to control the mechanisms of the Federal Government."
There are five states that Romney lost by substantially less than the number of people who actually voted for Paul in the primaries/caucuses, with an aggregate number of electoral votes to give him the win. If you assume that these Paul people would have voted for Romney if he'd won the nomination without massive cheating (as he probably would have) and instead sat it out (or enough other Republicans behaved that way to make up for Paulites who didn't) it would have been President Romney.
On the other hand, if Paul had managed to win the primary he'd likely have trounced Obama. He can pull support from much of the Democratic Party's base and enough of the typical Republican voters to make up for any that might have sat out HIS run.
Because "High Fructose Corn Syrup" rolls off the tongue slightly better than "a 50%:50% ±10% homogeneous mixture of fructose and glucose with >0.5% residual corn proteins and cellulose."
Not to mention bacteria enzymes.
My personal problem with HFCS is that I'm allergic to corn, and food-grade purification processes don't clean out enough of what I'm allergic to for ANY corn-sourced food ingredient to be safe for me. (As I understand it, antibodies are THE most sensitive detectors of particular molecules / molecular sites known to man, and it only takes four molecules to trigger an allergic reaction.) Fry it (ALL!) brown and it's safe, else forget it.
But I hear that HFCS is an obesity issue because it doesn't trip the appetite regulation as strongly as sucrose, so people tend to eat more of it.
$100+/bulb is VERY pricey. (Lots of LED bulbs already have TI radio/processor chips - usually the otherwise-identical ones with zigbee rather than BLE - for substantially less.
Adding a battery and related circuitry to do operate-over-power-failure is nice but not that much of a cost. Adding a speaker/microphone, a suitable processor to drive it, and some network and security software, may justify a substantial boost. But software amortizes to "almost free" over large numbers of units. So it seems to me the price point is too high. I expect this will die from competition.
... apparently you managed to find your way here in order to post this so it cannot have been much of a problem for you.
But how many people didn't figure it out. And how many valuable comments were lost as a result?
The CPU is also fast because it's made of small components close together. It's built using current large-chip fabrication technology. re-optimized for low leakage, of course.
When a substantial fraction of the target applications are intended to run for years on a fractional amp-hour lithium button or harvested ambient energy, power saving is critical.
If the CPU in the IoT Device is powerful enough to make offloading actually worthwhile, isn't that CPU way overkill for the IoT Device's primary function?
Not at all. The CPU is fast to reduce latency. This not only meets response targets, but it also means the CPU can shut down after a very short time, saving power.
This is especially important on battery powered devices. If the CPU is off except for a couple of milliseconds every few seconds, a battery can last for years.
The CPU is also fast because it's made of small components close together. It's built using current large-chip fabrication technology. Making it physically small means many chips per die, which means low cost per chip. If that makes it fast, so much the better .
As long as you're not using extra power to increase the speed further, there's no problem with a processor being "too fast". That just means it can go to sleep sooner. In fact, slowing it down can be expensive: Slower means not only that the power is on longer, but it also usually means bigger components which require more electrons to change their voltage. The more electrons delivered by the battery, the more if it is used up. Oops!
Granted that the processors are powerful and cheap, and have a lot of computation potential. But there are other downsides to trying to use IoT devices for a computing resource.
One is that the volatile memory, which uses scarce power just holding its state is very small, and the permanent memory, though it may be moderately large, is flash: VERY slow, VERY power consuming to do a write (and the processor stops while you're writing flash, screwing things up for its primary purpose).
Much of the current generation IoT devices run on either the Texas Instruments CC2541 (8051 processor, 8kB RAM, 256kB flash) and its relatives, or the Nordic nRF51822 (32-bit ARM® Cortexâ M0 CPU, 32kB/16kB RAM, 256kB/128kB flash) and its family, and the next generation is an incremental improvement rather than a breakthrough. You can do a lot in a quarter megabyte of code space (if you're willing to work at it a bit like we did in the early days of computing). But there's not a lot of elbow room there.
The tiny memories mean you don't have a lot of resource to throw at operating systems and extra work. In fact, though the communication stacks are pretty substantial (and use up a LOT of the flash!), the OSes are pretty rudimentary: Mostly custom event loop abstraction layers, talking to applications that are mostly event and callback handlers. Development environments encourage custom loads that don't have any pieces of libraries or system services that aren't actually used by the applications.
Another downside is the lack of bandwidth for communicating between them. (Bluetooth Low Energy, for example, runs at one megaBIT per second, has a lot of overhead and tiny packets, and divides three "advertising" (connection establishment) channels, in the cracks between 2.4GHz WiFI chnnels, among ALL the machines in radio "earshot".) Maybe they can do a lot of deep thought - but getting the work to, and the results from, all those little guys will be a bottleneck.
Maybe Moore's Law and the economic advantage of saving programmer time may make this change in the future. But I'm not holding my breath waiting for "smart" lightbulbs to have large, standardized, OSes making that "wasted" CPU power available to parasitic worms.