Forgot your password?

Comment: Re:Perfect Software (Score 1) 664

by ld a,b (#46313677) Attached to: Stack Overflow Could Explain Toyota Vehicles' Unintended Acceleration

Anyone who thinks all software has bugs has never written "Hello World" in assembly.

Perfect, trivial software is clearly possible. Perfect software that's slightly more complex is also clearly possible. We haven't yet accepted that perfect software is possible, but we should demand it (for moderately expensive software, or where bugs will cost you money, for instance). A reasonably intelligent programmer writing a modestly complex program should be able to do so perfectly. That he can't, (because his tools don't help him do so) is infuriating.

Yes, almost all software has bugs. We are way too comfortable with the idea. Software doesn't need to have bugs. We just don't have toolchains and development stacks that encourage perfect software. It's as if engineers decided to only use modeling clay for buildings, because nobody sells steel, and it's too cumbersome to smelt their own.

The profession really is no better off for accepting this sorry state.

Sorry, but you are wrong. A perfect Hello World written in assembly according to specification and formally proofed can have bugs in not one but two cases.

  • * The specifications are wrong.
  • * The CPU has a bug.

Hardware people can be clueless retards as well

CPU bugs are something you only read about in books until you actually try to do something non-trivial with the CPU.

Comment: Re:coding standards (Score 3, Informative) 664

by ld a,b (#46310545) Attached to: Stack Overflow Could Explain Toyota Vehicles' Unintended Acceleration
Sorry. I work in automotive embedded systems(although not personally in safety-critical parts we use the same parts and rules) and I can tell you rules like yours were behind this.

We are following all these rules and so we are safe. We can save a penny per 1000 units sold using a crappy MMU-less CPU.

First of all, following the stupid rules requires you to use baroque lint imitations which will go off on every line of idiomatic C. You need a paper trail to justify every line of code. Seems about right, people's lives are in danger, right?

Now consider that the controller system is hundreds of thousand of LOCs(for us it's more like millions). Most of that is crap boilerplate code required by the standards. This means if you follow that methodology strictly, you need hundreds of people going through mindnumbing lists of "You are not using this argument/This code assigning an argument to itself does nothing". Given that most software developers are inept and overworked, I can give you a certificate that there will be bugs.

It took me two weeks with the code to find a checksum function used all over the place that had been "fixed" to detect offset data after some earlier corruption bug was not detected.

Every 256 bytes "checksummed", a bit from the input would be left unaccounted(And it was actually used for data several times larger than that). I know for a fact that had to go through at least three source and design reviews and at least one more design review with some fat managers higher up.

Now tell me you feel safe.

Note to PHBs: Googleing up a fucking working CRC and getting a CS PhD to make a formal proof that it will work as intended would have cost far less.

Also, you see, the crappy CPU vendor stack measuring tools - that rules say we must use to guarantee safety - don't account for function pointers(they do show scary icons for recursive functions). They say foo(384) bar(uhhm... maybe 0?) I know to look for that when I add calls to function pointers, but I guess most people don't.

Now you add another rule. LOZRA 4092: You can't use function pointers at all.

Make my life more miserable, give the remaining work I will be unable to do to Dave, the monstera plant, or someone with the same programming aptitude.

I will give the crappy CPU/Compiler/RTOS vendors that should be sued free advice:

0- Add an MPU

1- Add canaries to every function call with any local variable at all(here it's not hackers it's programmers following LOZRA 396: cast the shit off everything so the compiler can't tell)

2- Add stack overflow canaries on every task switch. (add an MPU and align to page in the stack growing direction)

3- Add canaries to any memory pool allocation. (add MPU dead pages - You don't need RAM, just fucking address space of which you are using like 2%)

4- If any of the above traps, jump to a customer defined function(stored in ROM than can only be physically modified by outside hardware) that puts all vital hardware in a safe state, adds a record to the black box and reset the whole thing from scratch.

5- Forget about tasks and threads and move on to processes running on separate address spaces. If information must flow from a to b it better go through accepted channels. 6- Did I tell you to add a fucking MPU!?

Comment: Re:No surprise there (Score 1) 263

by ld a,b (#42084355) Attached to: After Weeks of Trying, UK Cryptographers Fail To Crack WWII Code
If you only have two messages you can only get K^A K^B and A^B. This doesn't directly give you the key.
However as A^B is just a plaintext encoded plaintext, decyphering both plaintexts is relatively easy. Where relatively here means infinitely easier than provable impossibility.
Ridiculously easy if A and B were black and white images. See
Getting the key is then trivial.

Comment: Re:any questions? (Score 1) 360

by ld a,b (#41758699) Attached to: Ask Slashdot: How To Avoid Working With Awful Legacy Code?
Your job is finding a way to both comply with their requirements and getting quality software out. If after thinking it through with your coworkers there is no way you could get it done, your job is then to tell them they are full of shit and go get us new requirements. If unresponsive repeat and rinse with their superiors.

Comment: Re:How about tri-ligual, quad-ligual ? (Score 2) 221

by ld a,b (#40884909) Attached to: Bilingual Kids Show More Creativity
It may be more the fact that her parents were switching randomly, than the number itself. We can have many neuronal paths in parallel but they are organized by context. switch(p){case MOM: l = Japanese; break; case DAD: l = Korean; break; case TEACHER: l = English; break;} is more optimal than if p=(p==MOM)?(p->l==Japanese)?Japanese:Korean:(p==DAD)(p->l==Korean)?Korean:English;.....

Comment: Re:He can't win (Score 1) 214

by ld a,b (#38848567) Attached to: Bill Gates Gives $750M To AIDS Fund

at least from when he started coding school systems to put him into classes with more girls

That is more "fucking awsome" than "bastard", even if today it would get his ass raped in some federal prison.
I'd say coding a BASIC interpreter in 4kb using paper and an emulator you hacked up for an unreleased platform is pretty cool as well.
Then he started hearing calls from the dark side and the rest is History.

All in all, I think he is an admirable man if only in the same category as Genghis Khan - who also did a lot genetic health related work for Eurasian people.

Comment: Re:Bone Parts? (Score 4, Interesting) 99

by ld a,b (#37807444) Attached to: German Paleontologists Find a 'Near-Perfect' Dinosaur Fossil
The arms in theropods are like avian wings in that for most species they are in a rigid clapping position. There was a Slashdot article about this some time ago. Actually clapping doesn't quite describe it as you'll find ancient bird fossils have their claws facing forwards just like this one.
The "damaged" hip is actually one of the two main features used to tell a theropod away from other dinosaurs. The theropods ischium is facing backwards, while their illium faces forwards. This is the ancestral configuration, although it was secondarily lost in the species most closely related to birds, which have *both* facing backwards,
Plant-eating Ornithischia, like the Triceratops, on the other hand, evolved that "new" hip configuration much earlier.

Comment: Re:Not that far-fetched (Score 1) 150

by ld a,b (#37204786) Attached to: When Algorithms Control the World
I am aware of hidden variables theories being dismissed by many. However, the probabilities can always be explained by hidden variables and vice versa. How could you tell a dead cat from an undead cat that died right after you looked at it?
My point was that we can't tell. I choose the explanation without pixie dust until it is definitely proven right or shown that the pixie dust behaves deterministically after all.
Newton's maths matched the world so closely until we realized they didn't. Nobody is discussing that QT is the best we have, but it can't even explain gravity, so it's safe to say it's at the very least incomplete.

Comment: Re:Not that far-fetched (Score 1) 150

by ld a,b (#37201572) Attached to: When Algorithms Control the World
Heisenberg's Uncertainty Principle is being taken too far by pop interpretations and by some physicists.
It just means we may never be able to confirm any theory on the laws governing quanta and that we have to use probabilistic interpretations instead. It doesn't mean there aren't deterministic rules governing them.

Applying Occam's razor to the problem tells us Schroedinger's experiment doesn't yield an undead cat until you look at it any more than killing your cat based on the 31415926535'th bit of the output of random(3)* with seed 0 would. The cat will die or it won't, "alea jacta est", you just can't tell until you run the experiment.

* random(3) is a misnomer. It is a PRNG.
Classic Games (Games)

Pac-Man's Ghost Behavior Algorithms 194

Posted by Soulskill
from the i-hate-the-pink-one dept.
An anonymous reader writes "This article has a very interesting description of the algorithms behind the ghosts in Pac-Man. I had no idea about most of this information, but that's probably because it's difficult to study the ghosts when I die every 30 seconds. Quoting: 'The ghosts are always in one of three possible modes: Chase, Scatter, or Frightened. The "normal" mode with the ghosts pursuing Pac-Man is Chase, and this is the one that they spend most of their time in. While in Chase mode, all of the ghosts use Pac-Man's position as a factor in selecting their target tile, though it is more significant to some ghosts than others. In Scatter mode, each ghost has a fixed target tile, each of which is located just outside a different corner of the maze. This causes the four ghosts to disperse to the corners whenever they are in this mode. Frightened mode is unique because the ghosts do not have a specific target tile while in this mode. Instead, they pseudorandomly decide which turns to make at every intersection.'"

Live within your income, even if you have to borrow to do so. -- Josh Billings