0 and 1 are probabilities as defined by modern probability theory.
That article you link to is non-mathematical bollocks that begs the question it's attempting to resolve. Worse than that - the "amusing anecdote" it links to is even worse.
># sed -i -e 's/admin/toor/g'/etc/passwd > >Well, that's a recipe for screwing things up on any modern Unix or Linux > system (shadow password file?
one new parameter to the sed
> home directories?
I was going to add an illustrative ``mv/home/admin/home/toor'' as I can't remember where home directories are in OSX, but I decided I didn't want to give OSX weenies the masturbatory pleasure of displaying how clever they were in correcting me.
> any config file that > references the account by name rather than UID?
Note that the OSX way also falls down on this final point too.
I have grep, and know how to use it. If their config files aren't in/etc/ or/var/, then it's probably not a program I have installed on my system. OSX is way more fragile in this regard, as the setting might be hidden in a binary file. I have changed the username of one of the accounts on one of my debian machines, the procedure was so simple and painless, and had no repercussions, I really don't remember anything about it - it was just click-click-click-done.
Oh - vipw's for wimps./etc/passwd's a text file, designed to be easily maintained by hand. If you can't hand edit it without fucking up, you don't deserve root permissions to the system.
Don't just point the finger at Windows. OSX is just as bad in places. Case in point - when my Mac was delivered, I was away on business, and my g/f set it up. I wasn't happy with the account name she chose for the administrative user. Expecting to need to do little more than # sed -i -e 's/admin/toor/g'/etc/passwd I was shocked to find that/etc/passwd was no longer where login names were managed. I asked several very smart guys who were seen as Mac gurus (perhaps only by themselves and other Mac users). They had no quick solution. They asked the people they considered gurus. They had no quick solution. Weeks later, we come to the conclusion that the only solution was this (the "For Mac OS X v10.4.11 and earlier" section): http://support.apple.com/kb/HT1428?viewlocale=en_US 43 fucking steps! That's insanity.
So clearly OSX does not have the Unix philosophy. I was informed that part of the problems were because of the underlying BSD, so not actually of Apple's creation. If that's so, then even Unix ain't so Unix-like any more.
There's at least a happy ending to the story - I'm happily running Debian linux/powerpc in the box now.
>> Why the hell would you expect the strings to be converted to some number though, when both operands are strings?
> Because that's the documented behavior
You have misinterpreted the question.
The question was not: "Why *in a program*, would you expect..." Which you answered by saying "because the language defines it that way". Factually correct, but not in any way useful.
The question was: "Why, *in a language*, would you expect..." which your answer doesn't even begin to address.
http://oss.digirati.com.br/mod_lua/2.0/faq.html """ Why does mod_lua's web site use PHP?
Because we must start the project from a point. The lua version is coming soon. """
Page Modified: Thu Feb 3 17:08:22 2005
I hate almost everything about PHP, I think Lua's kinda neat (but love spelling it LUA to wind up stupid fanboys), but the above doesn't say "for the win", it says "for the give up, then lose". (And yeah, there are other ways of interfacing Lua with port 80, I know, but given apache's popularity, in particular in 2005, one would reasonably be expected the primary focus to have been on mod_lua.)
"Or some sub state machines have to change depending of the state of the others"
Then the whole state machine is not anything like a direct product of two smaller state machines. I'm not talking 'sub-state-machines' I'm talking complete orthogonality.
"I so often fix so many broken design by killing thread and replacing them by a nice hierarchy of state machines and a lot of debug. All the synchronization problem magically disappear"
Understandable, synchronisation is hard to get right. And if you can't do it right, you definitely should be using multiple threads. I have some true horror stories on this topic, regarding a large chipset vendor and their kernel, but alas I'm under NDA.
If your state machine is the direct product of N simpler state machines, then in fact you've got a system with N independent states, and it is *best* modelled with N separate threads. OK, an exact direct product is unusual, but often it's not far from the truth. One of the biggest flaws I see in less experienced developers' code, is their inability to factor and simplify, and you then end up with one monster state machine of high complexity, and high defect count. So Cox was accidentally encouraging messy and flawed designs.
He seems to be ignoring the fact that it's possible for two parts of a modern computer to be doing different things at the same time, and without synchronisation. With an attitude like that, it's surprising he doesn't bin interrupts and DMA too.
Perhaps he prefers full task separation, but in that case he ought to make his bloody IPC more efficient!
(And yes, the swearing is in jest, I've worked as a linux kernel developer on the same project as Alan in the past.)
No - don't worry about pointers! We can fix that by introducing auto_ptr! (C++98) Oh, shit, auto_ptr is bollocks, let's remove it again (C++11)
Quite why anyone trusts these pollyannas with a programming language, I don't know. They'd be better suited to the fashion or pop music industry.
I just hope one of the ringleaders of fucking up C++, Andrei Alexandrescu, doesn't fuck up Digital Mars' D project to the same extent as he fucked up C++ - that used to be a good language.
> programmers only care about getting working, optimized code outputted
Thank got the groups I work with don't. They care about getting working, tested, maintainable code written. The fact that you even mentioned optimisation implies you're way too immature to understand software engineering yet.
> only use bounded functions like strncpy() rather than unbounded ones like strcpy().
Use of strncpy() is one of those shibboleths I use to detect if a programmer knows what he's doing or not. If he uses strncpy(), he probably does *not* know what he's doing. He's probably been told by idiots like you that the version with the 'n' is safer, and then uses it without thinking, not even knowing that sometimes it doesn't even leave you with a valid C string. strncpy() is *never* the best solution to a problem. strlcpy() is frequently the best solution, but alas doesn't have enough traction in WG14.
I never believed for one minute that the reality distortion field was so limited as to only be able to cover RAM choice.
I've always been a POWER fan (I've even worked for Freescale), and I found VT's "run it for one benchmark then dismantle it" to be an insult to the supercomputing field. Thank Knuth I'm not a US tax payer.
Just one word - bullshit! At least in the reporting.
Did noone else notice the "infinite capacity" in the link? I'm afraid that violates the laws of not just information theory, but of physics itself. Why should we trust any of their reporting when it's clear they don't know the subject matter they are reporting on?
It's much more an anthropological concept than a genetic one. No geneticist worth his salt would ever claim to have a scientifically justifiable is-or-is-not-the-same-race distinguisher. Only anthropologists are that brave.
Were only that the case. If you can't have ECC, then at least have a reality distortion field instead: http://everythingapple.blogspot.com/2004/07/virginia-tech-calls-original-power-mac.html
Looking down your nose and feeling superior to others is not hatred. We may have evidence of hatred of Apple, but we do not have evidence of hatred of those who buy apple.
Slashdot Mirror
0 and 1 are probabilities as defined by modern probability theory.
That article you link to is non-mathematical bollocks that begs the question it's attempting to resolve. Worse than that - the "amusing anecdote" it links to is even worse.
># sed -i -e 's/admin/toor/g' /etc/passwd
/home/admin /home/toor'' as I can't remember where home directories are in OSX, but I decided I didn't want to give OSX weenies the masturbatory pleasure of displaying how clever they were in correcting me.
/etc/ or /var/, then it's probably not a program I have installed on my system. OSX is way more fragile in this regard, as the setting might be hidden in a binary file. I have changed the username of one of the accounts on one of my debian machines, the procedure was so simple and painless, and had no repercussions, I really don't remember anything about it - it was just click-click-click-done.
/etc/passwd's a text file, designed to be easily maintained by hand. If you can't hand edit it without fucking up, you don't deserve root permissions to the system.
>
>Well, that's a recipe for screwing things up on any modern Unix or Linux
> system (shadow password file?
one new parameter to the sed
> home directories?
I was going to add an illustrative ``mv
> any config file that
> references the account by name rather than UID?
Note that the OSX way also falls down on this final point too.
I have grep, and know how to use it. If their config files aren't in
Oh - vipw's for wimps.
They've not been poking small vague abstract representations of things.
When you double-click on that little icon of the globe, it doesn't cause earthquakes.
Have you never aliased mroe? The shell can be made slightly fuzzy too.
> A command line is a line of text that is input for a command.
False. A command line is a line of text that is the command.
Don't just point the finger at Windows. OSX is just as bad in places. Case in point - when my Mac was delivered, I was away on business, and my g/f set it up. I wasn't happy with the account name she chose for the administrative user. Expecting to need to do little more than /etc/passwd /etc/passwd was no longer where login names were managed. I asked several very smart guys who were seen as Mac gurus (perhaps only by themselves and other Mac users). They had no quick solution. They asked the people they considered gurus. They had no quick solution. Weeks later, we come to the conclusion that the only solution was this (the "For Mac OS X v10.4.11 and earlier" section):
# sed -i -e 's/admin/toor/g'
I was shocked to find that
http://support.apple.com/kb/HT1428?viewlocale=en_US
43 fucking steps! That's insanity.
So clearly OSX does not have the Unix philosophy. I was informed that part of the problems were because of the underlying BSD, so not actually of Apple's creation. If that's so, then even Unix ain't so Unix-like any more.
There's at least a happy ending to the story - I'm happily running Debian linux/powerpc in the box now.
It becomes horrifically slow after a few days, so crashing weekly is a positive feature!
I'll see your n9 and raise you an n950. (But I, like all the n900 owners I know, am a keyboard fan.)
ZX Spectrum vs. vic20/C64 vs BBC
>> Why the hell would you expect the strings to be converted to some number though, when both operands are strings?
..."
..."
> Because that's the documented behavior
You have misinterpreted the question.
The question was not:
"Why *in a program*, would you expect
Which you answered by saying "because the language defines it that way". Factually correct, but not in any way useful.
The question was:
"Why, *in a language*, would you expect
which your answer doesn't even begin to address.
http://oss.digirati.com.br/mod_lua/2.0/faq.html
"""
Why does mod_lua's web site use PHP?
Because we must start the project from a point. The lua version is coming soon.
"""
Page Modified: Thu Feb 3 17:08:22 2005
I hate almost everything about PHP, I think Lua's kinda neat (but love spelling it LUA to wind up stupid fanboys), but the above doesn't say "for the win", it says "for the give up, then lose". (And yeah, there are other ways of interfacing Lua with port 80, I know, but given apache's popularity, in particular in 2005, one would reasonably be expected the primary focus to have been on mod_lua.)
"Or some sub state machines have to change depending of the state of the others"
Then the whole state machine is not anything like a direct product of two smaller state machines. I'm not talking 'sub-state-machines' I'm talking complete orthogonality.
"I so often fix so many broken design by killing thread and replacing them by a nice hierarchy of state machines and a lot of debug. All the synchronization problem magically disappear"
Understandable, synchronisation is hard to get right. And if you can't do it right, you definitely should be using multiple threads. I have some true horror stories on this topic, regarding a large chipset vendor and their kernel, but alas I'm under NDA.
If your state machine is the direct product of N simpler state machines, then in fact you've got a system with N independent states, and it is *best* modelled with N separate threads. OK, an exact direct product is unusual, but often it's not far from the truth. One of the biggest flaws I see in less experienced developers' code, is their inability to factor and simplify, and you then end up with one monster state machine of high complexity, and high defect count. So Cox was accidentally encouraging messy and flawed designs.
It would never work - death would be preferable!
You didn't say tested, and you didn't say maintainable, which are important.
You did say optimised, about which I refer you to Michael A. Jackson
He seems to be ignoring the fact that it's possible for two parts of a modern computer to be doing different things at the same time, and without synchronisation. With an attitude like that, it's surprising he doesn't bin interrupts and DMA too.
Perhaps he prefers full task separation, but in that case he ought to make his bloody IPC more efficient!
(And yes, the swearing is in jest, I've worked as a linux kernel developer on the same project as Alan in the past.)
No - don't worry about pointers! We can fix that by introducing auto_ptr! (C++98)
Oh, shit, auto_ptr is bollocks, let's remove it again (C++11)
Quite why anyone trusts these pollyannas with a programming language, I don't know. They'd be better suited to the fashion or pop music industry.
I just hope one of the ringleaders of fucking up C++, Andrei Alexandrescu, doesn't fuck up Digital Mars' D project to the same extent as he fucked up C++ - that used to be a good language.
> programmers only care about getting working, optimized code outputted
Thank got the groups I work with don't. They care about getting working, tested, maintainable code written. The fact that you even mentioned optimisation implies you're way too immature to understand software engineering yet.
> only use bounded functions like strncpy() rather than unbounded ones like strcpy().
Use of strncpy() is one of those shibboleths I use to detect if a programmer knows what he's doing or not. If he uses strncpy(), he probably does *not* know what he's doing. He's probably been told by idiots like you that the version with the 'n' is safer, and then uses it without thinking, not even knowing that sometimes it doesn't even leave you with a valid C string. strncpy() is *never* the best solution to a problem. strlcpy() is frequently the best solution, but alas doesn't have enough traction in WG14.
I never believed for one minute that the reality distortion field was so limited as to only be able to cover RAM choice.
I've always been a POWER fan (I've even worked for Freescale), and I found VT's "run it for one benchmark then dismantle it" to be an insult to the supercomputing field. Thank Knuth I'm not a US tax payer.
Indeed that is another posibility. Journalists nowadays are no better trained than store clerks.
Just one word - bullshit! At least in the reporting.
Did noone else notice the "infinite capacity" in the link? I'm afraid that violates the laws of not just information theory, but of physics itself. Why should we trust any of their reporting when it's clear they don't know the subject matter they are reporting on?
It's much more an anthropological concept than a genetic one. No geneticist worth his salt would ever claim to have a scientifically justifiable is-or-is-not-the-same-race distinguisher. Only anthropologists are that brave.
Were only that the case. If you can't have ECC, then at least have a reality distortion field instead:
http://everythingapple.blogspot.com/2004/07/virginia-tech-calls-original-power-mac.html
Looking down your nose and feeling superior to others is not hatred. We may have evidence of hatred of Apple, but we do not have evidence of hatred of those who buy apple.