Forgot your password?
typodupeerror

Comment: Re:What problem does this solve, again? (Score 1) 215

by lars_stefan_axelsson (#47808303) Attached to: Hidden Obstacles For Delivery Drones

The part I'm I think will be the big show-stopper is the likelihood of people 'catching goodies from the sky'. Given the technical restrictions of these drones it seems fair to assume they'll be used mostly for 'small but expensive' goods. What's to stop people from building a microwave-gun to fry the electronics and run of with the cargo ? Heck, a decent slingshot could probably bring them down. I realize one could rob any courier service, but with drones it's going to be dead-simple unless they start building in all kinds of security measures but thus limiting the capacity/range/... of the machine.

Yes, I was thinking "shotgun", but your ideas are better. Let's run with it a bit. How about a good old fashioned barrage balloon? Or use it to loft a fishing net, or why not a kite? "Honest officer, here I was just flying my kite, minding my own business and all these drones started to fall all around me, not my fault really..."

Or, for the ultimate thrill. Your own drone/RPV. There have been "dog fighting" competitions between RC-planes for ages, trying to cut someone else's streamer with your propeller. Now you could actually make that game worth your time.

Then there's good old fashioned GPS-spoofing that can be done for cheap. Make the drone land/drop thinking it has reached its destination? It's manna from heaven all over again, only this time courtesy of Amazon... :-)

Comment: Re:Slashdot comments indicative of the problem (Score 1) 1262

The patriarchy is crumbled and will die off with those that are 45+.

And you had me all the way up until you had to discriminate against me based on my age alone... :-)

Not all us 46-year olds are as bad as you think. Just so you know. Oh, and now you've had your say, get off my lawn, etc.

Comment: Re:CISC - reduced memory access ... (Score 1) 161

by lars_stefan_axelsson (#47786417) Attached to: Research Shows RISC vs. CISC Doesn't Matter

Much of the later complexity didn't exist in the late 70s.

Yes, I should have said that I put RISC as beginning with Hennessy & Patterson's work, that became MIPS and SPARC respectively. So we're a bit later than that. And of course when I said "compiler" I meant "optimizing compiler". Basic compilation as you say, was not a problem on CISC, but everybody observed that the instruction set wasn't really used. I remember reading VAX code from the C-compiler (on BSD 4.2) when I was an undergrad and noting that the enter/leave instructions weren't used. My betters answered: "Of course it isn't, they put so much useless stuff in there that it's much too slow..." (Only they didn't use the word "stuff"...)

But yes, the x86 is perhaps more "braindead" than "CISC" from that perspective, I was actually thinking VAX and it's ilk as they were what "RISC" came to replace, since the x86 wasn't a serious contender for workstations/minicomputers when they entered the arena. It was strictly for "PCs", which were a decidedly lesser class of computer, for lesser things. If anything RISC replaced the MC68000 and similar in the workstation space. And even though that was CISC, it was of course a much nicer architecture than Intels ever were, or became.

Comment: Re:It's a question that WAS relevant (Score 1) 161

by lars_stefan_axelsson (#47785811) Attached to: Research Shows RISC vs. CISC Doesn't Matter

The downside of having few registers in the ISA is it means the compiler may have to choose instruction ordering based on register availability or worse still "spill" registers to memory to fit the code to the available registers.

Yes, but the score boarding takes care of those spills as well. The processor won't actually perform them. But, whether they're visible or not, the compiler still has to optimise as if they're there in order to have a chance to wring out the maximum performance, so whether they're visible or not turns out to not mean that much in practice, rather, keeping them invisible isn't that much of a gain, as the compiler will have to assume that they're backed by invisible ones anyway and you'll take a substantial performance hit if they were ever to go away. (Which they won't as they take up next to no real estate today anyway.)

Comment: Re:CISC - reduced memory access ... (Score 1) 161

by lars_stefan_axelsson (#47785735) Attached to: Research Shows RISC vs. CISC Doesn't Matter

Yes, simplicity of design was important, but the simplicity was to free up chip resources to use elsewhere, not to make it easier for humans to design it.

Well, yes. I think we're forgeting one of the main drivers for RISC, and that was making the hardware more compatible with what the then current compilers could actually fruitfully use. Compilers couldn't (and typically didn't) actually use all the hideously complex instructions that did "a lot" and were instead hampered by lack of registers, lack of orthogonality etc. So there was a concerted effort to develop hardware that fit the compilers, instead of the other way around, which had been the dominating paradigm up to that point.

Take for example the MIPS without interlocked pipe-line stages. That was difficult for a human assembly coder to keep track of, but easy for a compiler, and it made the hardware design simpler and faster, so that's the way they went. (In fact, the assembler put in no-ops for you to fix inject pipeline stalls in order for your code to make sense when you programmed it in assembly. That made the object dump show stuff you didn't put there which was a bit disconcerting... :-))

Comment: Re:isn't x86 RISC by now? (Score 1) 161

by lars_stefan_axelsson (#47785697) Attached to: Research Shows RISC vs. CISC Doesn't Matter

CISC ISAs may have individual "complex" instructions, such as procedure call instructions, string manipulation instructions, decimal arithmetic instructions, and various instructions and instruction set features to "close the semantic gap" between high-level languages and machine code, add extra forms of data protection, etc. - although the original procedure-call instructions in S/360 were pretty simple, BAL/BALR just putting the PC of the next instruction into a register and jumping to the target instruction, just as most RISC procedure-call instructions do. A lot of the really CISCy instruction sets may have been reactions to systems like S/360, viewing its instruction set as being far from CISCy enough, but that trend has largely died out.

I know you say "current", but one of the original ideas behind RISC was also to make each instruction "short", i.e. make each instruction take one cycle, and reduce cycle times as much as possible so that you could have really deep pipelines (MIPS), or increase clock speed. Now, while most "RISCs" today, sort-of follow this idea, by virtue of the ISA having been made with that in mind in the old days, i.e. load-store etc. they're typically not as strict about it (if they in fact ever where). I guess the CISC situation is even more complicated, as they're "internally" RISC, and you can kind-a-sort-a treat them that way by staying away from the "heavy" instructions. That is if you can reason about what kind of time you're going to see from your micro-opped+out-of-order core anyway. The internals, and specifically the timing models have gotten even more complex than they already were. I don't know what your take on that would be?

Comment: Re:isn't x86 RISC by now? (Score 1) 161

by lars_stefan_axelsson (#47785651) Attached to: Research Shows RISC vs. CISC Doesn't Matter

And, given that most processors running GUI systems these days, and even most processors running GUI systems before x86/ARM ended up running most of the UI code people see, didn't have register windows, no, they're not needed. Yeah, SPARC workstations may have been popular, but I don't think register windows magically made GUIs work better on them. (And remember that register windows eventually spill, so once the stack depth gets beyond a certain point, I'm not sure they help; it's shallow call stacks, in which you can go up and down the call stack without spilling register windows, where they might help.)

I remember reading research back in the day, that showed that register windows were orthogonal to any RISC/CISC considerations, i.e. they were about as easy/costly to implement in either architecture and they gave the same boost/or not, in either case. As you point out, in practice it turned out to not be really worth the trouble, and they died out rather quickly.

Comment: Re: 20 failures from 6 million power cords? recall (Score 1) 137

by lars_stefan_axelsson (#47772513) Attached to: HP Recalls 6 Million Power Cables Over Fire Hazard

Generally the ones who have problems are the "vocal minority": that is, if you have problems, you are more likely to speak up, so if you're only seeing 20 / 13million, it could well indicate that the problem is quite limited.

Sure, I'm one of those. I raised hell, on a Swedish electrical/electronics forum... Didn't even bother to call HP. I assumed it was a one off, and what are they going to do anyway? Tell me to send the cable to them? (That's too much of a hassle) and give me a new one? (I could just grab a new one from one of the conveniently situated piles at work).

In fact, the usual rule, born out by science, when it comes to customer satisfaction here in Sweden (originally talking about large enterprises like TV/Radio) is that for every complaint you have 4000 people who are dissatisfied but don't bother to make contact.

Now, of course, a recall could still be warranted even if there were only 20 out of 6 million, since there shouldn't be any at all. Compare the Challenger disaster. That the O-rings had only been eroded through a third of the way, didn't really mean that they had a safety factor of three, since they weren't supposed to erode at all! Likewise, these cables weren't supposed to melt either, and by a substantial safety margin at that. If as many as 20 do, that means that there is a systematic error somewhere.

Comment: Re:Not the PSUs? The actual cables? (Score 1) 137

by lars_stefan_axelsson (#47772497) Attached to: HP Recalls 6 Million Power Cables Over Fire Hazard

With the limited info I have I would guess either a cheapskate manufacturer that tried to pass the wrong gauge of cable as the correct one or a crappy connection between a plug and the cable.

I have one of these cables and after having analysed it, we (the guys on the forum and I :-)) think its more an issue of "dirty" plastics. If they get, e.g. carbon in the plastics used for injection molding the plug, it will conduct a small current, which will lead to heat, which will lead to charring, which will lead to more conduction, and you have a vicious circle going. So just to be clear, it's the "Mickey Mouse" plug that plugs in to the PSU that's faulty, not the PSU as such.

In my own case, the cable finally conducted enough to trip the RDC on my house, and that's when I started investigating. Having confirmed the problem, I then remembered the time on the airplane across the Atlantic when my socket wouldn't stay on, or the time on the train when the whole side of my car kept switching off... I had inadvertently travelled the world, leaving darkness and despair in my wake...

Pictures of my measurements (and discussion, in Swedish I'm afraid). At 20mA, the cable developed 4.6W and my measured 80C (176F) is reasonable. I didn't really notice it before, since the powersupply gets quite warm as it is.

Comment: Re:I love getting into strangers' cars (Score 1) 273

You have the same amount of "skin in the game", whether the man is driving a paying fare or giving a free ride to a friend.

No, frequency and other conditions are different. It's not an accident that you can bring your friends with you in your small aircraft with just an ordinary (sport) pilot license. If you want to take a paying passenger then you need a transport pilot license.

Same with boats.

Why are taxis different?

The wherewithal comes simply from experience --- not from a license.

And that's (drum roll) one of the conditions of a taxi (i.e. commerical) license in my country. Having sufficient experience that is. The license is there to (among other things) show that you have that experience.

Comment: Re:I love getting into strangers' cars (Score 1) 273

And why must "higher level of skills" be a requirement â" even for the customers, who are perfectly satisfied with average level of skills?

Well, the customers are not the only ones with skin in the game. The rest of us have to share the roads with these "taxis" as well. The major reason that other commercial drivers (or air line pilots for that reason) isn't that they'll necessarily will kill their passengers, but that they will kill a bystander or other motorists. The rules for getting a bus driving license and a heavy truck driving license are the virtually the same, here in Sweden at least, and in one of those cases we're clearly not worried by the safety of the passengers.

It's the same at sea and in the air, if you want to transport paying passengers you have to show a higher level of competence. One reason mentioned in those cases is that you for example have to have the wherewithal to be able to stand up to a pissed off customer when you deem conditions to be unsafe, something that's more difficult (legally/financially) than when you have another passenger.

Comment: Re:Not convinced (Score 5, Insightful) 176

And also something I came to value when working in industry and developing both cli and GUI admin tools for telecoms equipment:

You can easily document, email and (to a lesser extent) talk about a cli. A GUI not so much. When you've tried to walk someone through finding the hidden option in a GUI over the phone for the tenth time you're ready to tear your hair out. With a cli you can just email some commands and that's that. Documenting a GUI invariably devolved to a lot of screenshots which makes any workflow tens of pages long, instead of ten lines of commands which you then have ample space to explain and comment on. It's also much easier to read and follow along as you're e.g. installing, than leafing through screenshot after screenshot.

Comment: Re:Thanks for pointing out the "briefly" part. (Score 1) 461

by lars_stefan_axelsson (#47327381) Attached to: Half of Germany's Power Supplied By Solar, Briefly

It verges on astounding. I've read for years that Germany has ceded sovereign control of its land to Russia for natural gas, and that German citizens would freeze by the tens of thousands if Putin turned off the taps.

And that's largely still true as a matter of fact. HOWEVER, Germany relies less on Putin's gas than Putin relies on Germany's money for that gas. (I.e. the value of Germany's gas imports as a part of their energy expenditure is small compared to the overall hard currency income that Putin receives from selling gas to Europe). Hence we're witnessing the situation with gas used as a weapon against the Ukraine and Belarus, but not against Germany.

That's not to say that it won't happen. Just that it takes more will on the Russian side than what they've been able to muster so far. Don't for a minute think that it doesn't factor in the decisions of Frau Merkel when it comes to sanctions against Russia for their part in the Ukraine debacle though. We would probably be tougher from the European side if it weren't for that gas...

Comment: Re:Thanks for pointing out the "briefly" part. (Score 1) 461

by lars_stefan_axelsson (#47327321) Attached to: Half of Germany's Power Supplied By Solar, Briefly

Oh, then I'm sure you'll find an insurance company that will cover the risk of Fukushima-style accidents. Oh wait, no you don't, because such an insurance would make nuclear energy totally uneconomic.

OTOH, the largest hydro electric dam failures have killed thousands (tens of thousands for the very largest) and you know what: They largest dams are typically insured "by the government" in the same way that nuclear is.

Now, you can actually buy hydro dam insurance on the open market, while that is generally impossible for nuclear, but they don't typically pay without bounds for incidental damage which is the major cost we're facing. Instead relying on government for that part, so while there is some difference, the scenarios are quite similar.

Machines certainly can solve problems, store information, correlate, and play games -- but not with pleasure. -- Leo Rosten

Working...