As someone who actually *has* a clue, I can tell you that writing drivers for linux is NOT a mess and that it IS easy. It was easy with 2.4.X. It became even easier with 2.6.X. In fact, if you're too slow to pick it up from the *publically-available* sources at kernel.org, there are TWO BOOKS written on the subject. There is nothing to fix, as there is nothing broken. No, Linux will *not* support a never-changing binary API . Supporting it will only result in a Linux equivalent of the driver hell over at Windows - remember the Windows 9x USB fiasco? You want a never changing API? Then do what NVIDIA did. Write your OWN never-changing API/ABI, and recompile that for every kernel on the planet at install - now you can keep your proprietary skeletons in the closet and STILL not piss-off linux users. And exactly why do you think its easy to develop drivers for Windows? Did you ever write one? Hell, did you even ever code or do something BESIDES spreading FUD on/.?
Whats broken with linux drivers support? Have you actually written one, or are you just spreading FUD? I'll say FUD.
Its hard to install nvidia drivers? Nope../nvidia-installer. Whew, that was... ummm... "hard." You want to bitch, maybe, about FireGL (I have no clue, since... well.. I don't have an ATi, but I have heard its not as simple)? Then bitch to ATi, and don't blame Linux. Doom 3 running at 1 fps instead of 2 fps? Boo freakin' hoo. Considering that ATi and NVidia aren't baseing their success on support of a niche community, be *glad* they even care. Don't like their work? Write your own. Its not the Linux kernel's fault though.
You ARE spreading FUD. You claim that every year that new ATi and NVidia chips come out, only Windows gets support. But you are clearly wrong. ATi has support for their X800 PCIe cards in FireGL and NVIDIA has support for their 6X00 series as well. What the hell are you talking about?
I agree. But to some degree, that problem is still localized to USER FILES, and doesn't immediately involve system files. (unless you're dumb and run as root... or the virus "happens" to prey on some unpatched binary with a priv-escalation problem). An annoyed admin can say... just type rm -rf/home/luser and likely ensure thats the end of that story. In Windows..heh... sometimes its a screwed up process of disabling Windows System File Protection, going into safe mode, cleaning your system files (default user perms under XP are essentially root perms, so ummm... yeah), re-enable FS protection and rebooting back. Ugh.
I think the best linux ELF virus would be one that sets up a backdoor and posts IP to some IRC chan, allowing humans to come in and poke around for files to leech and/or local holes to exploit.
Documents to Go... *shudder*. *THAT* is one shitty app. I can't think if DtG or Palm's mail client is a worse offender - they have a penchant for cluttering your memory with little pieces of turd left everywhere - about a 100 PRCs and PDBs.
Your problem does sound like a HW problem, since you experienced it on a Palm that you didn't put any software yet on. What model is this? Palm isn't renowned for their support (just like everyone else, *sigh*). I'm just happy I got one of the newer NON-Peeling-Paint Zire72s. I personally can't wait till Palm switches to Linux Kernel + PalmOS6 GUI. That means that someone would figure out a way to backport linux onto the by-then "older" Palms like my current Zire72.
No, "we" won't. Worst that can happen is ~/bin and ~/lib getting infected, if you/have/ anything there, that is. And if you're bright enough to use root as your every-day account, well, you deserve getting your system 0wned.
Funny how I've yet to cause my Zire to crash. As long as you avoid the urge to put as much junk sharewarez on your PDA, you'll be fine. It all crap anyways. If you stick to Palm apps and open source proggies you'll be fine.
Ahh, but as long as you have a pointer to be manipulated, you can use it to overwrite the return address without touching the canary. Of course, nowadays funny things like StackGuard XOR the canary with the return address preventing such attacks while StackShield mirrors return address information, preventing such attacks - but it doesn't prevent exploiting. As long as you have a pointer to be manipulated there are OTHER things you can modify besides the return address. You can modify the fnlist entry for exit, for one thing. You can modify the GOT entries too.
In short, if there is a need, there is always a way.
I beg to differ. That address will differ from system to system, but it will NOT differ on the same system or from program run to program run. Sorry bub, libc gets loaded by ld.so at exactly the same place.
---------> (gdb) break main Breakpoint 1 at 0x8048d77: file nasm.c, line 150. (gdb) run Starting program:/home/andyw/nasm-0.98.38/nasm
Breakpoint 1, main (argc=1, argv=0xbffffa04) at nasm.c:150 150 pass0 = 1; (gdb) print system $1 = {<text variable, no debug info>} 0x410598a0 <system> (gdb) ------------> (gdb) break main Breakpoint 1 at 0x804838a (gdb) run Starting program:/home/andyw/a
Breakpoint 1, 0x0804838a in main () (gdb) print system $1 = {<text variable, no debug info>} 0x410598a0 <system> ------------>
Thus if I have local access, return-to-libc exploits are easy-peasy. If I'm striving for a remote exploit... then I'll want to exactly match the OS/Distro/program-in-question on my "development" machine.
No.
The 286 was a completely new core than the 8086/80186. It added the 16-bit protected mode and allowed access to up to 16mb of memory.(24-bit bus).
The 386 was a completely new core. The 486 built based on the 386. The Pentium was a completely different core. The Pentium Pro was a revolutionary different core - PII/III are based on the same PPRO core, along with the P-M. IMHO PPro was ahead of its times and is still the best core they've got compared to the horrible flop AKA P4. IMHO PPro was better than the PII (at matching clock speeds), since the PII was nerfed/reworked to perform "better" at 16-bit since the PPro wasn't good at it.
Floppy is by far the worst. In fact, even if you don't do anything stupid with the media (bend/light-on-fire/soak/place-near-speakers) - it still can crap out on you at any moment. And... as my box of 5 1/4" floppies can testify - do not age very well either.
CDs, when done properly - i.e. without using some ghetto glue to attach the substrate to the shiny layer - will last, properly handled, for a long time. I do have CDs that suffered bit rot, but those are thankfully few, and once again... due to shoddy manufacturing. I feel really sad that the caddy system (now used with BlueRay? I think?) has disappeared from the CD scene. It was clearly the best way to handle the media.... which is why I still use a 10 year-old SCSI Toshiba CD-ROM wiht a Caddy in my workstation.
I think solid state media is really the way to go, but I wish MO media wasn't killed off so fast. It was a good idea.
...And Yule. (Think Northern lands). Easter "just happens" to coincide with the Ostara's Day (notice any similarity in naming;-)). Intersting that although in Germanic countries "Ostara's Day" became Easter through the wonders of sword-and-commerce conquests, the name for Easter in Romance countries such as Italy is derived from a bastardisation on the hebrew word for passover.
Btw, all those cutesy things like Easter Eggs, Easter Bunny, Christmas (really Yule) Tree, carolling and getting completely *cough* soused are all really european pagan things and have nothing to do with Christianity per-se. Nice to know that I can still celebrate Christmas and Easter while being pagan, since I'm REALLY celebrating Yule and Ostara's day. Heheh. I digress.
GlÃgg for real' (a hot mulled wine with spices, red wine, port and brandy)
Yup, also known as Gluehwein (Germany) and Gloeg (Sweden). Red wine yes. (Many) Spices? Yes. Hot? Yup. Port? I don't think Portwine is part of the recipe... neither is Brandy for that matter. (The real question is errm... WHY... and... ugh that would taste odd). Anyways, good stuff though.
Not necessarily. Until the beginning of this year I've had about 7 machines in my room - simply for the love of computers, not even necessarily out of some use. Besides my Athlon XP workstation and laptop, I had a couple of 486s (one with VLB card and VLB IDE lol), an Amiga 3000, a dual 604e PowerMac clone running Debian and a Pentium Pro file server. Before we moved into our new house, I also had some strange EISA 386 machine and an IBM PS/2 M55 with 2.9MB of memory and a 60MB ESDI disk, onto which I forced my custom linux distro (based off Slack 3.2) - but I had to let them go unfortunately.
Now I only have two computers since I decided to clear my room and find other hobbies...err... get a life. Its significantly quieter in my room now (less fans) and I picked up some other hobbies, but still no life.
Not an (i|Power)Book owner (yet!!) but AFAIK there is no Airport Express support in YDL. So if you have an iBook or PB12" you will have to get a USB WiFi adapter, or get another PCMCIA WiFi card for the rest of the PBs. I recommend anything based on the PrismII chipset (use wlan, orinoco_cs, or hostap drivers). Btw, if you are going to buy a Linksys WPC11 - get v.3. AVOID WPC11 v.4 - its based around some obscure Realtek chipset and the drivers suck (and are x86 only, and crash on anything older than 2.4.18).
http://alumni.imsa.edu/~andyw/projects/wpc11v4.htm l
Yes, AFAIK the (some?) instructions in all the IA-32 processors are converted into micro-opcodes. I know for sure that such is the case with the Athlons and the Transmeta chips since they *cough* emulate the IA-32.
IA-32 is most definitely not RISC and PowerPC is most definitely not CISC, but both are chimeras as the line between whats RISC and whats CISC is starting to blur a lot.
Anyone who still judges the value of a CPU by whether its "RISC" or "CISC", by clock speed or by computrons/bogons needs to get of his pedestal and get with the Naughts.:-))
Bring out the CISC-versus-RISC skeleton was not a very good decision, simply because it Doesn't Apply (TM). Face it - most processors in the 21st century are a *&$#( to classify as either RISC or CISC.
Lets see the current facts: 1) The clearly CISC-ish IA-32, at the current stage has half its 8086/80186/80286 (and I do mean the 16-bit) instruction set deprecated. Those *complex action performing* instructions have not had any performance edge over the simpler once since the days of the 80486, and shouldn't be used... unless your prerogative is code-size rather than performance. So, in other words, it is now/preferred/ to program as if IA-32 was RISC-ish. See gcc -S output. Finally, the traditional characteristic of RISC processors, yes pipelining, has been available for ages the IA-32. So... is it pure CISC? Maybe not?
2) The clearly RISC-ish PowerPC received a healthy injection of CISC-ishness with the arrival of Motorola's Altivec in G4. Sorry, those SIMD extensions are not RISC-ish. So is this a pure RISC? Maybe not?
There are plenty of reasons to hate the IA-32. As a kernel developer (homebrew project) I find the IA-32 a register-starved architecture, systems programming for which is a pain-in-the-ass considering the oddball hacks that the Protected Mode and IBM's design of the IBM PC AT were. As a neophyte PowerPC assembly programmer (I did hack Quik to remove the stupid linux kernel size restriction though). I thoroughly enjoy the PPC ISA and I am in love with the PPC memory management facilities.
It is a stupid to claim that Apple laptops consume less power simply because x86 is CISC(ish) and THUS uses more power. Design matters, but implementation matters too. Take a look over at the Athlon. The Athlon is its own architecture that has an x86 personality (apparently emulates the IA-32) - but the design of the processor has nothing to do with any Intel design. Looking even at Intel designs, the P3 (... and Penium M) and P4 designs differ. The P3 builds on the success of the Pentium Pro/II while P4 is well... IMHO a flop... and intel should just lean on the Pentium M.
It is not prudent to claim that the latest IA-32 and AMD-64 processors owe anything more to the 8086 MCU other than a half of largely unused, despised, deprecated performance-lacking instructions as well as opcode compatibility.
There are plenty of reason why I am soon to put $1k into the purchase of an iBook - but not because PowerPC "is a a RISC-based architecture" unlike that "aging, bulky CISC" x86.
Slashdot Mirror
As someone who actually *has* a clue, I can tell you that writing drivers for linux is NOT a mess and that it IS easy. It was easy with 2.4.X. It became even easier with 2.6.X. In fact, if you're too slow to pick it up from the *publically-available* sources at kernel.org, there are TWO BOOKS written on the subject. There is nothing to fix, as there is nothing broken. No, Linux will *not* support a never-changing binary API . Supporting it will only result in a Linux equivalent of the driver hell over at Windows - remember the Windows 9x USB fiasco? You want a never changing API? Then do what NVIDIA did. Write your OWN never-changing API/ABI, and recompile that for every kernel on the planet at install - now you can keep your proprietary skeletons in the closet and STILL not piss-off linux users. And exactly why do you think its easy to develop drivers for Windows? Did you ever write one? Hell, did you even ever code or do something BESIDES spreading FUD on /.?
./nvidia-installer. Whew, that was... ummm... "hard." You want to bitch, maybe, about FireGL (I have no clue, since... well.. I don't have an ATi, but I have heard its not as simple)? Then bitch to ATi, and don't blame Linux. Doom 3 running at 1 fps instead of 2 fps? Boo freakin' hoo. Considering that ATi and NVidia aren't baseing their success on support of a niche community, be *glad* they even care. Don't like their work? Write your own. Its not the Linux kernel's fault though.
Whats broken with linux drivers support? Have you actually written one, or are you just spreading FUD? I'll say FUD.
Its hard to install nvidia drivers? Nope.
You ARE spreading FUD. You claim that every year that new ATi and NVidia chips come out, only Windows gets support. But you are clearly wrong. ATi has support for their X800 PCIe cards in FireGL and NVIDIA has support for their 6X00 series as well. What the hell are you talking about?
I agree. But to some degree, that problem is still localized to USER FILES, and doesn't immediately involve system files. (unless you're dumb and run as root... or the virus "happens" to prey on some unpatched binary with a priv-escalation problem). An annoyed admin can say... just type rm -rf /home/luser and likely ensure thats the end of that story. In Windows..heh... sometimes its a screwed up process of disabling Windows System File Protection, going into safe mode, cleaning your system files (default user perms under XP are essentially root perms, so ummm... yeah), re-enable FS protection and rebooting back. Ugh.
I think the best linux ELF virus would be one that sets up a backdoor and posts IP to some IRC chan, allowing humans to come in and poke around for files to leech and/or local holes to exploit.
Yeh unfortunately thats clearly the case... ... well I guess I'll go back to fondling my Amiga A3000. Happy New Years. :-D
Documents to Go... *shudder*. *THAT* is one shitty app. I can't think if DtG or Palm's mail client is a worse offender - they have a penchant for cluttering your memory with little pieces of turd left everywhere - about a 100 PRCs and PDBs. Your problem does sound like a HW problem, since you experienced it on a Palm that you didn't put any software yet on. What model is this? Palm isn't renowned for their support (just like everyone else, *sigh*). I'm just happy I got one of the newer NON-Peeling-Paint Zire72s. I personally can't wait till Palm switches to Linux Kernel + PalmOS6 GUI. That means that someone would figure out a way to backport linux onto the by-then "older" Palms like my current Zire72.
No, "we" won't. Worst that can happen is ~/bin and ~/lib getting infected, if you /have/ anything there, that is. And if you're bright enough to use root as your every-day account, well, you deserve getting your system 0wned.
Funny how I've yet to cause my Zire to crash. As long as you avoid the urge to put as much junk sharewarez on your PDA, you'll be fine. It all crap anyways. If you stick to Palm apps and open source proggies you'll be fine.
Elaborate. Maybe its 4:10 AM, or maybe I'm missing something?
MMM I forgot about things like PaX, however as you can see... PaX isn't exactly commonplace, eh?
Ahh, but as long as you have a pointer to be manipulated, you can use it to overwrite the return address without touching the canary. Of course, nowadays funny things like StackGuard XOR the canary with the return address preventing such attacks while StackShield mirrors return address information, preventing such attacks - but it doesn't prevent exploiting. As long as you have a pointer to be manipulated there are OTHER things you can modify besides the return address. You can modify the fnlist entry for exit, for one thing. You can modify the GOT entries too.
In short, if there is a need, there is always a way.
I beg to differ. That address will differ from system to system, but it will NOT differ on the same system or from program run to program run. Sorry bub, libc gets loaded by ld.so at exactly the same place.
/home/andyw/nasm-0.98.38/nasm
/home/andyw/a
--------->
(gdb) break main
Breakpoint 1 at 0x8048d77: file nasm.c, line 150.
(gdb) run
Starting program:
Breakpoint 1, main (argc=1, argv=0xbffffa04) at nasm.c:150
150 pass0 = 1;
(gdb) print system
$1 = {<text variable, no debug info>} 0x410598a0 <system>
(gdb)
------------>
(gdb) break main
Breakpoint 1 at 0x804838a
(gdb) run
Starting program:
Breakpoint 1, 0x0804838a in main ()
(gdb) print system
$1 = {<text variable, no debug info>} 0x410598a0 <system>
------------>
Thus if I have local access, return-to-libc exploits are easy-peasy. If I'm striving for a remote exploit... then I'll want to exactly match the OS/Distro/program-in-question on my "development" machine.
So this takes care of... what... one silly way to control the instruction pointer? NX won't help against a return-to-libc or formatted-string exploit.
No. The 286 was a completely new core than the 8086/80186. It added the 16-bit protected mode and allowed access to up to 16mb of memory.(24-bit bus). The 386 was a completely new core. The 486 built based on the 386. The Pentium was a completely different core. The Pentium Pro was a revolutionary different core - PII/III are based on the same PPRO core, along with the P-M. IMHO PPro was ahead of its times and is still the best core they've got compared to the horrible flop AKA P4. IMHO PPro was better than the PII (at matching clock speeds), since the PII was nerfed/reworked to perform "better" at 16-bit since the PPro wasn't good at it.
Infidel. I find WASD the best controlls ever.
Floppy is by far the worst. In fact, even if you don't do anything stupid with the media (bend/light-on-fire/soak/place-near-speakers) - it still can crap out on you at any moment. And... as my box of 5 1/4" floppies can testify - do not age very well either.
CDs, when done properly - i.e. without using some ghetto glue to attach the substrate to the shiny layer - will last, properly handled, for a long time. I do have CDs that suffered bit rot, but those are thankfully few, and once again... due to shoddy manufacturing. I feel really sad that the caddy system (now used with BlueRay? I think?) has disappeared from the CD scene. It was clearly the best way to handle the media.... which is why I still use a 10 year-old SCSI Toshiba CD-ROM wiht a Caddy in my workstation.
I think solid state media is really the way to go, but I wish MO media wasn't killed off so fast. It was a good idea.
...And Yule. (Think Northern lands). Easter "just happens" to coincide with the Ostara's Day (notice any similarity in naming ;-)). Intersting that although in Germanic countries "Ostara's Day" became Easter through the wonders of sword-and-commerce conquests, the name for Easter in Romance countries such as Italy is derived from a bastardisation on the hebrew word for passover.
;-D.
Btw, all those cutesy things like Easter Eggs, Easter Bunny, Christmas (really Yule) Tree, carolling and getting completely *cough* soused are all really european pagan things and have nothing to do with Christianity per-se. Nice to know that I can still celebrate Christmas and Easter while being pagan, since I'm REALLY celebrating Yule and Ostara's day. Heheh. I digress.
Merry whatever
GlÃgg for real' (a hot mulled wine with spices, red wine, port and brandy)
Yup, also known as Gluehwein (Germany) and Gloeg (Sweden). Red wine yes. (Many) Spices? Yes. Hot? Yup. Port? I don't think Portwine is part of the recipe... neither is Brandy for that matter. (The real question is errm... WHY... and... ugh that would taste odd). Anyways, good stuff though.
Not necessarily. Until the beginning of this year I've had about 7 machines in my room - simply for the love of computers, not even necessarily out of some use. Besides my Athlon XP workstation and laptop, I had a couple of 486s (one with VLB card and VLB IDE lol), an Amiga 3000, a dual 604e PowerMac clone running Debian and a Pentium Pro file server. Before we moved into our new house, I also had some strange EISA 386 machine and an IBM PS/2 M55 with 2.9MB of memory and a 60MB ESDI disk, onto which I forced my custom linux distro (based off Slack 3.2) - but I had to let them go unfortunately.
Now I only have two computers since I decided to clear my room and find other hobbies...err... get a life. Its significantly quieter in my room now (less fans) and I picked up some other hobbies, but still no life.
It wasn't funny the first time you posted it... why would you think it would be the second time you mentioned it?
c id=11177628
First mentioning: http://linux.slashdot.org/comments.pl?sid=133880&
Active dislike of Sendmail for security reasons, AND a user of QMail?
:-)
D. J. Bernstein, is that you?
http://cr.yp.to/
Its FreeBSD? The only distro of FreeBSD is (duh!) FreeBSD, lol. RTFA.
Not an (i|Power)Book owner (yet!!) but AFAIK there is no Airport Express support in YDL. So if you have an iBook or PB12" you will have to get a USB WiFi adapter, or get another PCMCIA WiFi card for the rest of the PBs. I recommend anything based on the PrismII chipset (use wlan, orinoco_cs, or hostap drivers). Btw, if you are going to buy a Linksys WPC11 - get v.3. AVOID WPC11 v.4 - its based around some obscure Realtek chipset and the drivers suck (and are x86 only, and crash on anything older than 2.4.18). http://alumni.imsa.edu/~andyw/projects/wpc11v4.htm l
Yes, AFAIK the (some?) instructions in all the IA-32 processors are converted into micro-opcodes. I know for sure that such is the case with the Athlons and the Transmeta chips since they *cough* emulate the IA-32.
:-))
IA-32 is most definitely not RISC and PowerPC is most definitely not CISC, but both are chimeras as the line between whats RISC and whats CISC is starting to blur a lot.
Anyone who still judges the value of a CPU by whether its "RISC" or "CISC", by clock speed or by computrons/bogons needs to get of his pedestal and get with the Naughts.
Grouping the hex into bytes doesn't help either.. since 14 isn't a letter in ASCII... Not UTF8 either. Maybe UTF16, but I doubt it.
What does this have to with TFA though? And who used the fugly "segment cludge" ever since the 80286 (yes, 286 - 16-bit pmode) came out?
Bring out the CISC-versus-RISC skeleton was not a very good decision, simply because it Doesn't Apply (TM). Face it - most processors in the 21st century are a *&$#( to classify as either RISC or CISC.
/preferred/ to program as if IA-32 was RISC-ish. See gcc -S output. Finally, the traditional characteristic of RISC processors, yes pipelining, has been available for ages the IA-32. So... is it pure CISC? Maybe not?
Lets see the current facts:
1) The clearly CISC-ish IA-32, at the current stage has half its 8086/80186/80286 (and I do mean the 16-bit) instruction set deprecated. Those *complex action performing* instructions have not had any performance edge over the simpler once since the days of the 80486, and shouldn't be used... unless your prerogative is code-size rather than performance. So, in other words, it is now
2) The clearly RISC-ish PowerPC received a healthy injection of CISC-ishness with the arrival of Motorola's Altivec in G4. Sorry, those SIMD extensions are not RISC-ish. So is this a pure RISC? Maybe not?
There are plenty of reasons to hate the IA-32. As a kernel developer (homebrew project) I find the IA-32 a register-starved architecture, systems programming for which is a pain-in-the-ass considering the oddball hacks that the Protected Mode and IBM's design of the IBM PC AT were. As a neophyte PowerPC assembly programmer (I did hack Quik to remove the stupid linux kernel size restriction though). I thoroughly enjoy the PPC ISA and I am in love with the PPC memory management facilities.
It is a stupid to claim that Apple laptops consume less power simply because x86 is CISC(ish) and THUS uses more power. Design matters, but implementation matters too. Take a look over at the Athlon. The Athlon is its own architecture that has an x86 personality (apparently emulates the IA-32) - but the design of the processor has nothing to do with any Intel design. Looking even at Intel designs, the P3 (... and Penium M) and P4 designs differ. The P3 builds on the success of the Pentium Pro/II while P4 is well... IMHO a flop... and intel should just lean on the Pentium M.
It is not prudent to claim that the latest IA-32 and AMD-64 processors owe anything more to the 8086 MCU other than a half of largely unused, despised, deprecated performance-lacking instructions as well as opcode compatibility.
There are plenty of reason why I am soon to put $1k into the purchase of an iBook - but not because PowerPC "is a a RISC-based architecture" unlike that "aging, bulky CISC" x86.