Go look at any components distributor, and you'll find ample documentation for all sorts of hardware, especially for commodity stuff.
BTW, those are simply components. Consumer hardware is a complex collection of all those parts, usually containing its own set of interfaces and design features. Not to mention all the hardware that uses custom ASIC chips (pretty much everything), FPGAs (common alternative to an ASIC), and complex software drivers (e.g. Video cards, Wifi, Modems, etc.) that contain all the logic necessary to actually use the hardware for the intended purpose.
Basically, what you're saying is "here's a video card that uses brand XYZ Digital YUV to Analog DVI coverter chip, go write a driver for it." Everyone else just sort of looks at you with their mouths hanging open as thoughts of frame buffers, multi-pipelined 3D texturing units, video overlays, Video ROM code, and other complex features float through their heads.
This is a myth perpetuated by PC hardware manufacturers somehow thinking they're special.
No, try again. The whole driver issue is one of the wiser things that Microsoft ever did. Back in the day hardware manufacturers made hardware, and software providers were expected to purchase the specs and implement their own drivers. Microsoft (despite being a fairly large company) realized that there was no way they could keep ahead of the driver game, so they used their clout in the PC industry to force (yes, force) hardware manufacturers to write drivers for their Windows Operating System.
Microsoft wasn't stupid. They realized that there are serious advantages to distributing the development among companies other than themselves. Sadly, the Linux developers haven't wrapped their heads around this concept yet.
All a vendor needs to do is to make good, solid interface documentation, and make it available without NDAs and other childish restrictions, and the drivers will not only be written, but they'll probably be shipped with the operating systems, and for the most part, just work.
You're ignoring a LOT of the praticalities of the matter. Many driver manufactuers can't provide OSS drivers or the necessary info because:
1) It's against the law to provide methods for tampering with the equipment. (e.g. Wifi cards.)
2) Much of the code and/or hardware design is licensed from other parties, and they can't get permission to open it.
3) The ever important Time to Market consideration would be quashed if manufacturers had to wait for the driver to enter the tree then get distributed to the major Linux distros before releasing their hardware.
Besides, most hardware vendors don't want to maintain drivers for Windows, MacOS, FreeBSD, NetBSD, OpenBSD, BeOS, HURD, Xen, Linux, Solaris, and each of the incompatible versions of each of them, as well as any new platforms that arise.
That's why hardware manufacturers would like to see specifications like UDI and NDISfollowed. Unfortunately, those wonderful software people who are apparently so much better at this stuff have decided that they don't need anything as passe as a cross-platform driver API. Mr. Stallman is leading the charge on this one. Personally, I think he's stuck on stupid, but that's just me.
Here's my personal feelings on this. In the short term driver code has value to manufacturers for whatever IP it may contain. In the long term, driver code has precisely zero value to the OSS community. All they do is allow for more old cruft to hang around. I also think that supporting a cross-platform driver would make everyone's lives easier as Windows, Linux, FreeBSD, and whoever else can simply use the same drivers. Such a world would be a hardware Utopia in comparison to the driver issues we have today.
Stupid question: is it possible (with the current kernel architecture) to have them run in userspace?
Yes. There are quite a few drivers out there that run in Userspace and only use various port commands to access the hardware. It can still screw things royally (true of any software that mucks at that low of a level), but an overflow, NPE, or divide by zero is unlikely to screw the running kernel.
As you say, though, the problem is that it's God awful SSLLLLLOOOOOOWWWWWW. (Insert the 6Million$Man/BionicWoman "Wa wa wa wa wa" sound *here*.) It would be so nice to have an Object Oriented Operating System that doesn't need such crude concepts as rings of hell^W^W^W^W protection mode access.
I'm not as think you drunk as I am. *hiccup* (That soda pop must have been extra bubbly.:-P)
Step awaaay from the song lyrics...:P
No, you step back! I've got campy song lyrics and I'm not afraid to use them! I'm serious man! I'm listening to Madonna's "Burning Up" at this moment, and I'm just crazy enough to use them!;-)
God, I'm having WAY too much fun with these campy songs. More soda pop, please!
Nah. Doesn't have that same sort of simple and strong sound that mingles with fireworks very well. If you're looking for something more appropriate, try Twisted Sister. Goes well with shotguns and grenade launchers:
"Oh We're Not Gonna Take It!"
Blam! Blam!
"no, We Ain't Gonna Take It!"
Thump! Whiiiizzzzz...
"oh We're Not Gonna Take It Anymore!"
BOOOOOOMMMM!!
"we've Got The Right To Choose And..."
Splooosh!
"there Ain't No Way We'll Lose It!"
Blam! Blam! (tat-tat-tat in the distance) Thump! Whiiiizzzz...
"this Is Our Life, This Is Our Song"
KAAAAABOOOOOOOOMMMM! (Jolly Roger flies high on the defending ship in defiance of the Pirates!)
There are tons of ways. Depends on what you're doing.:-)
If you're just trying to process the data in large chunks, then wrap the InputStream in a BufferedInputStream before passing it to the DataInputStream. That will fill the buffer with size-configurable chunks of data every time it underflows rather than reading each byte individually. After that, the individual readUnsignedByte() calls don't matter. (CPU time is a few orders of magnitude cheaper than disk I/O, especially given the burst abilities of modern drives.)
For maximum buffer performance, you can check the file size before loading and size the buffer to load the whole thing. Or you can simply pass a byte[] array of the right size to the FileInputStream, then initialize a ByteArrayInputStream wrapped in a DataInputStream object.
If you're looking to do fast transforms on a lot of unsigned data, then what you need is ByteBuffers. These come in Byte, Short, Int, and Char form, and can be used to perform various types of SIMD instructions and/or access the data without bounds checking.
well, I'm guessing that, depending on where you are in the world, Rap music might be substituted.
I hate to burst your bubble, but the vehicle mounted version of these weapons are already in heavy use by Gangstas across the US! Just visit Chicago sometime and I guarantee you'll end up in a drive-by LRAD at least once!
The most shocking part is that these dangerous weapons are reaching the hands of our kids! Think of the children! Won't someone, please think of the children?!
I noticed your correction about the signed/unsigned bit, the point of my post was to point out that char is unsigned (you said all primitives are signed).
Ah, ok. I see your point. Another poster and I had already discussed that in the same thread. FYI, 'char' doesn't really count because it isn't actually a number, its a binary representation of a 16-bit Unicode character. It has to be converted to an INT before any operations can be performad on it. INTs are of course, signed.
Actually in UTF-8 some characters are single byte.
Java Chars are not UTF-8. They're full 16 bit Unicode characters. The lower 127 values, of course, map to the ASCII character set. As for storing/transmitted values, using a Reader or Writer will properly handle the Unicode encoding whether you're using UTF-8 or UTF-16. That's why you're not supposed to load strings the way I did in my original post.;-)
All signs point to linux having anywhere from the same market share as macs up to 3 times the market share of macs, particularly if you take into account webservers which would not show up in places like traditional webstats because web servers don't browse web sites, same thing for HPCs.
But you'd need to do the same for Macs. Not that I'm saying that Apple is selling more X-Serve Units than Linux installs out there, but the figures for Macs won't show up in the same way that the Linux figures don't show up. It's especially important not to discount Macs as the WebObjects platform is very popular.
Take into account that alot of linux boxes are old as well as new, meaning that alot of people who run linux often run more then one linux box, some of which may be a decade or so old (or much older in some cases). The average wintel box is replaced every 2~3 years. That means, for the sake of argument, if I set up a linux box today and a windows box, in 6 years after the first wintel box is replaced,Microsoft will have 2 "points" and linux will have 1 even though there is still 1 linux box and 1 wintel box running.
I don't really buy this argument. Most Linux users I've seen reinstall their system for every major update, which tends to come more often than Windows. This is something of a requirement as software support isn't as long lasting on Linux as it is on Windows. i.e. Many developers make a concious effort to support machines going all the way back to Win98. Linux developers OTOH tend to target the latest GLIBC, thus requiring that the user churn through new installations at a fairly good clip. BSD machines seem to have a bit longer lifespan, but they also suffer from upgrade-or-die-itis. In the case of FreeBSD, however, the system is designed to be easily upgraded via a system recompile. (Which amazingly tends not to break things.)
But as far as your little rant goes, this is an exploit in php and only php.
Incorrect. It's an exploit against the AWStats CGI script and the PHP XML-RPC APIs. Apparently it can also exploit WebHints. (Whatever that is.)
But it is even more specific than that, you must have a very speicific configuration which pretty much allows anyone to own your machine.
It is a very common configuration. Hundreds of inexpensive web hosts offer AWStats, and many personal web servers run it to track traffic. There are a LOT of people who are vulnerable to this exploit. Especially since people think of AWStats as being something hidden that only they can see. Why would they upgrade?
But just in case you forgot, Mac OSX does have its problems, despite the limited amount of software that comes with them and the limited liability that Apple takes.
What's interesting though is the exploits themselves. Security experts have to really work to find an exploit, and most of the ones they find are impossible to actually exploit under any normal circumstances. e.g. If you check the link you provided, you'll notice how many say "local exploit" on them. As in, you need direct access to the machine before it can be exploited. Under Windows, already having access to the machine is the end of the world unless the user has explicitly locked things down. Under Linux, it depends on the quality of the security configuration. A smart admin would be using SUDO and time-lock screensavers. Not all systems are configured this way, however.
Apple's track record is on par with any linux distro, for instance Debian or Fedora, but this actually means that Apple's record is worse because in a distro like Debian or Fedora, these projects take responsibility for something like 10,000 packages.
That's a non-argument. Macs do everything the users want them to do and yet remain secure. That's the key point. Sometimes less is more.
True, very true. Unfortunately, AWStats is extremely popular on personal and small business web servers. Its presence is extremely probable as it's a free and feature complete log analyzer.:-(
I really do wonder if the script can infect an OS X machine running AWStats? Many posters seem to think the answer is 'No'. Sadly, the article is shy on details, but I think the answer may be 'Yes'. Which could make this the first available Mac OS X Virus.
What's really interesting, however, is the fact that the worm is very similar to the Slapper worm. The only difference is that it exploits common PHP/CGI software rather than Apache itself. A coincidence, or a new revision of the same virus?
Except that in order to be attacked, you must have AWStats or WebHints installed. i.e. This isn't corporate software being attacked. It's technologists and power-users who run their own websites.
Linux has a smaller Market Share than Mac OS X, yet it's still getting targetted by virus writers? Is there something wrong with this picture?
If the target server is running one of the vulnerable scripts at specific URLs and is configured to permit external shell commands and remote file download in the PHP/CGI environment, a copy of the worm could be downloaded and executed.
*cough*Wouldn't have happened with a J2EE server.*cough*
And in one fell swoop, this virus helpfully explains to everyone why there is a market for J2EE servers, why people use Macs as their Desktops, and why Linux's reputation isn't quite spotless in comparison to Mac OS X. This is particularly interesting because we've had this discussion in several other threads with many people saying that the whole "no viruses" marketing applies as equally to Linux as it does to Macs. Similarly, many have said that PHP is just as useful for Enterprise work as J2EE. Yet these are the types of things these systems were designed to prevent.
Perhaps the most interesting thing is that a Mac *could* be vulnerable to this attack. Yet 99.9% of the Macs out there aren't, because the system doesn't ship with the web server running by default. In other words, Linux is making Microsoft's mistakes all over again.:-(
Dude, you seem to have a serious case of "acting before you think". First you correct a mistake that I'd corrected myself (the signed/unsigned thing that everyone except you noticed), now you're correcting something I just pointed out myself. From the post you replied to:
"Every character is a 16 bit Unicode character. That's why you're not supposed to do what I just did in the example above"
Dunno. I think you can just exit the shell, but don't quote me on that. A friend showed me the username trick, but I've never had a reason to use it. I can run graphical terminals just fine, so it seems like more of a cutesy trick than an actually useful procedure. I'm sure there are others who find it useful, though.:-)
Eh, I'll give you that one. Apple was obviously trying to keep it simple, but they sacrified just a bit too much. With Spotlight however, the Finder problems are far less noticable.
2) Having Obj-C API for nearly everything. This is improving, but it's still like pulling teeth to write a custom menu, for example.
* AKAImBatman thinks hard
Low level drivers are about all I can come up with. There's alternative APIs (such as Carbon vs. Cocoa), but those are pretty much just alternatives. Cocoa is all NeXT stuff with a few minor API improvements.
There's also the Java and C <-> ObjC bridge that allows the APIs to talk. It's a bit of a PITA since the different languages don't map all that well, but it works.
3) GDB was much more aware of Obj-C on NeXTSTEP. I didn't have to cast every bloody expression I wanted to evaluate.
Fair enough. I haven't written too much software on the Mac that I've needed to load into a debugger (I try to avoid the #*$@$ things anyway) so I'll give you that one.
3) A working mail services API.
Whoa. Deja Vu. 3+1=3? Did someone just mess with the matrix? (Kidding!)
I haven't messed with the Mail API at all (I much prefer Java with things get dicey), but isn't the whole Mail.app thing a direct port from NeXT? I would have thought that the mail APIs would have gone with it.
Indeed. It's not like we don't have SQL Databases pouring out of our ears. Today you can chose from PostGreSQL, MySQL, McKoi, Firebird, Derby, HSQL, Daffodil One$DB, SAP DB (the less said about that twisted codebase, the better), and a metric kilotonne more that I haven't even mentioned. What do we need *another* DB for, especially when it's out of date?
I'm far more pleased with the focus on Java databases like Derby and HSQL, plus the work going into XML Databases like Apache Xindice. All that work is extremely useful for portable applications, and has far more uses than Yet Another Crufty Codebase (TM).
On a serious note, what is it that you Next fans think is missing from OS X? Sure, they simplified things A LOT, but I think it's for the better. For example, the right click menus were just too unweildly (despite the power once you were used to them) and the screen border dock just didn't hold a candle to the new auto-resizing dock. Under the hood, all the APIs are the same, so what's the big deal?
You can get HFSTAR (attribute preserving TAR) from Fink. Not that it's necessary. Apple fixed the BSD utilities in 10.4. Hasn't anyone been paying attention?;-)
I have used OS X a bit. UNIX it ain't. When you can use tar, cpio or hell, ANY command line tool to back one up and get a usable machine back, I'll look at it again.
What makes you think you can't? That's pretty much what support does when they need to send your machine somewhere where they might reformat it. Bootloader issues still apply, but that's true of any OS.
Just like any other Unix, there are also ways to boot without the GUI. (IIRC, you can turn off the clickable username and type ">console" to get to the CLI. Another way is to modify the/etc/ttys file.) Reminds me quite a bit of a Solaris box, only the console mode isn't as pretty.
Sooo, I'm not really sure what you're argument is here.
Gimme a 'nipple mouse' with a proper complement of three buttons on a machine with the build quality of a Thinkpad for a comparable price and I'll look.
1) I hate nipple mice. A *REAL* mouse is a trackball, but they don't make those in laptops anymore. I usually carry a small optical, USB mouse in my pack for when I set up at a desk.
2) I hate thinkpads. The *#$@#$! things were always failing back when I was an administrator. The execs thought they were great, though. In my experience, the Apples tend to be MUCH tougher and withstand far more abuse. For example, I had the screen bent backwards on my iBook. It amazingly survived with only a minor warping of the case.
3) The prices of Apple Laptops *ARE* comparable to Thinkpads. I'm not certain where you get the idea that they aren't. Take this page and this page as examples. The prices line up pretty well, but in every instance the Thinkpad has a slower processor, less memory, and a smaller hard drive for the same price.
Besides, 3.8 pounds is a form factor Apple couldn't touch. A notebook computer that is actually about the size and weight of a notebook, imagine that.
You know what used to piss me off when I had to admin the IBM notebooks? The fact that IBM moved all the peripherals and power blocks outside of the case, so they could claim far lower weights than anyone else. Our execs would carry just as much weight as the field laptops (if not more) but they felt better about it because the specs *said* that the IBM was lighter. If you add the peripherals back into the machine (which can be difficult with IBMs, as many of them only allow for one item to be internal while the rest are external) they are often heavier than the competition.
One option we tried to offer our execs were the Sony Vaios. All the capabilities of the IBM Thinkpads, even stronger case, but 1/4 the weight. Sadly, the Vaios didn't look professional enough (being targetted at multimedia applications) and didn't go over with Mohagony Row.
Now for one thing an IBM Laptop will never be able to compete with: Sleep Mode. Apples are EXTREMELY nice in this area. No one ever shuts down or reboots their machines. They just close them or reopen them, and they work flawlessly every time. Windows Laptops tend to have all kinds of issues with this.
The only glitches I still have are dock related. No hot or warm docking/undocking, CD drive accesses at only 4X (on the dock) and the USB ports on the dock don't work.
That's not such a good dock. I've used several docks (which all seem to have worked better than yours) and I can't say I've been impressed. They always seem to be more trouble than their worth. Now the Mac, I have everything build in, so I don't need to worry about having access to my CD Drive or USB ports. They're right there and convenient to use. (On the side, not the back.) Instead of docking, just plug in the monitor, keyboard, mouse, and power
Slashdot Mirror
s/Analog DVI/Analog VGA/g
DVI is a psuedo digital signal, so that would be a bad example.
Go look at any components distributor, and you'll find ample documentation for all sorts of hardware, especially for commodity stuff.
BTW, those are simply components. Consumer hardware is a complex collection of all those parts, usually containing its own set of interfaces and design features. Not to mention all the hardware that uses custom ASIC chips (pretty much everything), FPGAs (common alternative to an ASIC), and complex software drivers (e.g. Video cards, Wifi, Modems, etc.) that contain all the logic necessary to actually use the hardware for the intended purpose.
Basically, what you're saying is "here's a video card that uses brand XYZ Digital YUV to Analog DVI coverter chip, go write a driver for it." Everyone else just sort of looks at you with their mouths hanging open as thoughts of frame buffers, multi-pipelined 3D texturing units, video overlays, Video ROM code, and other complex features float through their heads.
This is a myth perpetuated by PC hardware manufacturers somehow thinking they're special.
No, try again. The whole driver issue is one of the wiser things that Microsoft ever did. Back in the day hardware manufacturers made hardware, and software providers were expected to purchase the specs and implement their own drivers. Microsoft (despite being a fairly large company) realized that there was no way they could keep ahead of the driver game, so they used their clout in the PC industry to force (yes, force) hardware manufacturers to write drivers for their Windows Operating System.
Microsoft wasn't stupid. They realized that there are serious advantages to distributing the development among companies other than themselves. Sadly, the Linux developers haven't wrapped their heads around this concept yet.
All a vendor needs to do is to make good, solid interface documentation, and make it available without NDAs and other childish restrictions, and the drivers will not only be written, but they'll probably be shipped with the operating systems, and for the most part, just work.
You're ignoring a LOT of the praticalities of the matter. Many driver manufactuers can't provide OSS drivers or the necessary info because:
1) It's against the law to provide methods for tampering with the equipment. (e.g. Wifi cards.)
2) Much of the code and/or hardware design is licensed from other parties, and they can't get permission to open it.
3) The ever important Time to Market consideration would be quashed if manufacturers had to wait for the driver to enter the tree then get distributed to the major Linux distros before releasing their hardware.
Besides, most hardware vendors don't want to maintain drivers for Windows, MacOS, FreeBSD, NetBSD, OpenBSD, BeOS, HURD, Xen, Linux, Solaris, and each of the incompatible versions of each of them, as well as any new platforms that arise.
That's why hardware manufacturers would like to see specifications like UDI and NDIS followed. Unfortunately, those wonderful software people who are apparently so much better at this stuff have decided that they don't need anything as passe as a cross-platform driver API. Mr. Stallman is leading the charge on this one. Personally, I think he's stuck on stupid, but that's just me.
Here's my personal feelings on this. In the short term driver code has value to manufacturers for whatever IP it may contain. In the long term, driver code has precisely zero value to the OSS community. All they do is allow for more old cruft to hang around. I also think that supporting a cross-platform driver would make everyone's lives easier as Windows, Linux, FreeBSD, and whoever else can simply use the same drivers. Such a world would be a hardware Utopia in comparison to the driver issues we have today.
Stupid question: is it possible (with the current kernel architecture) to have them run in userspace?
Yes. There are quite a few drivers out there that run in Userspace and only use various port commands to access the hardware. It can still screw things royally (true of any software that mucks at that low of a level), but an overflow, NPE, or divide by zero is unlikely to screw the running kernel.
As you say, though, the problem is that it's God awful SSLLLLLOOOOOOWWWWWW. (Insert the 6Million$Man/BionicWoman "Wa wa wa wa wa" sound *here*.) It would be so nice to have an Object Oriented Operating System that doesn't need such crude concepts as rings of hell^W^W^W^W protection mode access.
Dude, are you friggin' drunk?!
:-P)
:P
;-)
I'm not as think you drunk as I am. *hiccup* (That soda pop must have been extra bubbly.
Step awaaay from the song lyrics...
No, you step back! I've got campy song lyrics and I'm not afraid to use them! I'm serious man! I'm listening to Madonna's "Burning Up" at this moment, and I'm just crazy enough to use them!
God, I'm having WAY too much fun with these campy songs. More soda pop, please!
And thanks to Google, you can be too!
:-P
Don't forget to pick up "Forever in Blue Jeans" and "Sweeeeeeeeeeeet Caroliiiiiiinnne!" (Bum... bum... baaaaaa!) while you're there.
Ok, I'm having way too much fun with this.
There are tons of ways. Depends on what you're doing. :-)
If you're just trying to process the data in large chunks, then wrap the InputStream in a BufferedInputStream before passing it to the DataInputStream. That will fill the buffer with size-configurable chunks of data every time it underflows rather than reading each byte individually. After that, the individual readUnsignedByte() calls don't matter. (CPU time is a few orders of magnitude cheaper than disk I/O, especially given the burst abilities of modern drives.)
For maximum buffer performance, you can check the file size before loading and size the buffer to load the whole thing. Or you can simply pass a byte[] array of the right size to the FileInputStream, then initialize a ByteArrayInputStream wrapped in a DataInputStream object.
If you're looking to do fast transforms on a lot of unsigned data, then what you need is ByteBuffers. These come in Byte, Short, Int, and Char form, and can be used to perform various types of SIMD instructions and/or access the data without bounds checking.
well, I'm guessing that, depending on where you are in the world, Rap music might be substituted.
I hate to burst your bubble, but the vehicle mounted version of these weapons are already in heavy use by Gangstas across the US! Just visit Chicago sometime and I guarantee you'll end up in a drive-by LRAD at least once!
The most shocking part is that these dangerous weapons are reaching the hands of our kids! Think of the children! Won't someone, please think of the children?!
Man, that would be sweet if you combined it with a Howitzer and some shoulder rockets.
They'll be running for their lives before you know it. Never underestimate the force multipling effect of a little psychological warfare.
I noticed your correction about the signed/unsigned bit, the point of my post was to point out that char is unsigned (you said all primitives are signed).
;-)
Ah, ok. I see your point. Another poster and I had already discussed that in the same thread. FYI, 'char' doesn't really count because it isn't actually a number, its a binary representation of a 16-bit Unicode character. It has to be converted to an INT before any operations can be performad on it. INTs are of course, signed.
Actually in UTF-8 some characters are single byte.
Java Chars are not UTF-8. They're full 16 bit Unicode characters. The lower 127 values, of course, map to the ASCII character set. As for storing/transmitted values, using a Reader or Writer will properly handle the Unicode encoding whether you're using UTF-8 or UTF-16. That's why you're not supposed to load strings the way I did in my original post.
All signs point to linux having anywhere from the same market share as macs up to 3 times the market share of macs, particularly if you take into account webservers which would not show up in places like traditional webstats because web servers don't browse web sites, same thing for HPCs.
:-)
But you'd need to do the same for Macs. Not that I'm saying that Apple is selling more X-Serve Units than Linux installs out there, but the figures for Macs won't show up in the same way that the Linux figures don't show up. It's especially important not to discount Macs as the WebObjects platform is very popular.
Take into account that alot of linux boxes are old as well as new, meaning that alot of people who run linux often run more then one linux box, some of which may be a decade or so old (or much older in some cases). The average wintel box is replaced every 2~3 years. That means, for the sake of argument, if I set up a linux box today and a windows box, in 6 years after the first wintel box is replaced,Microsoft will have 2 "points" and linux will have 1 even though there is still 1 linux box and 1 wintel box running.
I don't really buy this argument. Most Linux users I've seen reinstall their system for every major update, which tends to come more often than Windows. This is something of a requirement as software support isn't as long lasting on Linux as it is on Windows. i.e. Many developers make a concious effort to support machines going all the way back to Win98. Linux developers OTOH tend to target the latest GLIBC, thus requiring that the user churn through new installations at a fairly good clip. BSD machines seem to have a bit longer lifespan, but they also suffer from upgrade-or-die-itis. In the case of FreeBSD, however, the system is designed to be easily upgraded via a system recompile. (Which amazingly tends not to break things.)
But as far as your little rant goes, this is an exploit in php and only php.
Incorrect. It's an exploit against the AWStats CGI script and the PHP XML-RPC APIs. Apparently it can also exploit WebHints. (Whatever that is.)
But it is even more specific than that, you must have a very speicific configuration which pretty much allows anyone to own your machine.
It is a very common configuration. Hundreds of inexpensive web hosts offer AWStats, and many personal web servers run it to track traffic. There are a LOT of people who are vulnerable to this exploit. Especially since people think of AWStats as being something hidden that only they can see. Why would they upgrade?
But just in case you forgot, Mac OSX does have its problems, despite the limited amount of software that comes with them and the limited liability that Apple takes.
What's interesting though is the exploits themselves. Security experts have to really work to find an exploit, and most of the ones they find are impossible to actually exploit under any normal circumstances. e.g. If you check the link you provided, you'll notice how many say "local exploit" on them. As in, you need direct access to the machine before it can be exploited. Under Windows, already having access to the machine is the end of the world unless the user has explicitly locked things down. Under Linux, it depends on the quality of the security configuration. A smart admin would be using SUDO and time-lock screensavers. Not all systems are configured this way, however.
Apple's track record is on par with any linux distro, for instance Debian or Fedora, but this actually means that Apple's record is worse because in a distro like Debian or Fedora, these projects take responsibility for something like 10,000 packages.
That's a non-argument. Macs do everything the users want them to do and yet remain secure. That's the key point. Sometimes less is more.
Thank you for the well reasoned argument.
True, very true. Unfortunately, AWStats is extremely popular on personal and small business web servers. Its presence is extremely probable as it's a free and feature complete log analyzer. :-(
I really do wonder if the script can infect an OS X machine running AWStats? Many posters seem to think the answer is 'No'. Sadly, the article is shy on details, but I think the answer may be 'Yes'. Which could make this the first available Mac OS X Virus.
What's really interesting, however, is the fact that the worm is very similar to the Slapper worm. The only difference is that it exploits common PHP/CGI software rather than Apache itself. A coincidence, or a new revision of the same virus?
Except that in order to be attacked, you must have AWStats or WebHints installed. i.e. This isn't corporate software being attacked. It's technologists and power-users who run their own websites.
Linux has a smaller Market Share than Mac OS X, yet it's still getting targetted by virus writers? Is there something wrong with this picture?
:-(
If the target server is running one of the vulnerable scripts at specific URLs and is configured to permit external shell commands and remote file download in the PHP/CGI environment, a copy of the worm could be downloaded and executed.
*cough*Wouldn't have happened with a J2EE server.*cough*
And in one fell swoop, this virus helpfully explains to everyone why there is a market for J2EE servers, why people use Macs as their Desktops, and why Linux's reputation isn't quite spotless in comparison to Mac OS X. This is particularly interesting because we've had this discussion in several other threads with many people saying that the whole "no viruses" marketing applies as equally to Linux as it does to Macs. Similarly, many have said that PHP is just as useful for Enterprise work as J2EE. Yet these are the types of things these systems were designed to prevent.
Perhaps the most interesting thing is that a Mac *could* be vulnerable to this attack. Yet 99.9% of the Macs out there aren't, because the system doesn't ship with the web server running by default. In other words, Linux is making Microsoft's mistakes all over again.
Gee. wonder why I said that?
Dunno. I think you can just exit the shell, but don't quote me on that. A friend showed me the username trick, but I've never had a reason to use it. I can run graphical terminals just fine, so it seems like more of a cutesy trick than an actually useful procedure. I'm sure there are others who find it useful, though. :-)
1) Workspace.app. The Finder is a train wreck.
Eh, I'll give you that one. Apple was obviously trying to keep it simple, but they sacrified just a bit too much. With Spotlight however, the Finder problems are far less noticable.
2) Having Obj-C API for nearly everything. This is improving, but it's still like pulling teeth to write a custom menu, for example.
* AKAImBatman thinks hard
Low level drivers are about all I can come up with. There's alternative APIs (such as Carbon vs. Cocoa), but those are pretty much just alternatives. Cocoa is all NeXT stuff with a few minor API improvements.
There's also the Java and C <-> ObjC bridge that allows the APIs to talk. It's a bit of a PITA since the different languages don't map all that well, but it works.
3) GDB was much more aware of Obj-C on NeXTSTEP. I didn't have to cast every bloody expression I wanted to evaluate.
Fair enough. I haven't written too much software on the Mac that I've needed to load into a debugger (I try to avoid the #*$@$ things anyway) so I'll give you that one.
3) A working mail services API.
Whoa. Deja Vu. 3+1=3? Did someone just mess with the matrix? (Kidding!)
I haven't messed with the Mail API at all (I much prefer Java with things get dicey), but isn't the whole Mail.app thing a direct port from NeXT? I would have thought that the mail APIs would have gone with it.
Indeed. It's not like we don't have SQL Databases pouring out of our ears. Today you can chose from PostGreSQL, MySQL, McKoi, Firebird, Derby, HSQL, Daffodil One$DB, SAP DB (the less said about that twisted codebase, the better), and a metric kilotonne more that I haven't even mentioned. What do we need *another* DB for, especially when it's out of date?
I'm far more pleased with the focus on Java databases like Derby and HSQL, plus the work going into XML Databases like Apache Xindice. All that work is extremely useful for portable applications, and has far more uses than Yet Another Crufty Codebase (TM).
Not quite yet, but maybe after 10.5...
On a serious note, what is it that you Next fans think is missing from OS X? Sure, they simplified things A LOT, but I think it's for the better. For example, the right click menus were just too unweildly (despite the power once you were used to them) and the screen border dock just didn't hold a candle to the new auto-resizing dock. Under the hood, all the APIs are the same, so what's the big deal?
You can get HFSTAR (attribute preserving TAR) from Fink. Not that it's necessary. Apple fixed the BSD utilities in 10.4. Hasn't anyone been paying attention? ;-)
Well... It's still catching up to NeXTSTEP in some ways. :D
/ME munbles something about the fact that Mac OS X *IS* NextSTEP. ;-)
Hosea also married:
:-)
Good call. Hosea was the exception that proved the rule, as God was trying to make a point through his marriage.
Nice, well reasoned comments.
Thank you.
I have used OS X a bit. UNIX it ain't. When you can use tar, cpio or hell, ANY command line tool to back one up and get a usable machine back, I'll look at it again.
/etc/ttys file.) Reminds me quite a bit of a Solaris box, only the console mode isn't as pretty.
What makes you think you can't? That's pretty much what support does when they need to send your machine somewhere where they might reformat it. Bootloader issues still apply, but that's true of any OS.
Just like any other Unix, there are also ways to boot without the GUI. (IIRC, you can turn off the clickable username and type ">console" to get to the CLI. Another way is to modify the
Sooo, I'm not really sure what you're argument is here.
Gimme a 'nipple mouse' with a proper complement of three buttons on a machine with the build quality of a Thinkpad for a comparable price and I'll look.
1) I hate nipple mice. A *REAL* mouse is a trackball, but they don't make those in laptops anymore. I usually carry a small optical, USB mouse in my pack for when I set up at a desk.
2) I hate thinkpads. The *#$@#$! things were always failing back when I was an administrator. The execs thought they were great, though. In my experience, the Apples tend to be MUCH tougher and withstand far more abuse. For example, I had the screen bent backwards on my iBook. It amazingly survived with only a minor warping of the case.
3) The prices of Apple Laptops *ARE* comparable to Thinkpads. I'm not certain where you get the idea that they aren't. Take this page and this page as examples. The prices line up pretty well, but in every instance the Thinkpad has a slower processor, less memory, and a smaller hard drive for the same price.
Besides, 3.8 pounds is a form factor Apple couldn't touch. A notebook computer that is actually about the size and weight of a notebook, imagine that.
You know what used to piss me off when I had to admin the IBM notebooks? The fact that IBM moved all the peripherals and power blocks outside of the case, so they could claim far lower weights than anyone else. Our execs would carry just as much weight as the field laptops (if not more) but they felt better about it because the specs *said* that the IBM was lighter. If you add the peripherals back into the machine (which can be difficult with IBMs, as many of them only allow for one item to be internal while the rest are external) they are often heavier than the competition.
One option we tried to offer our execs were the Sony Vaios. All the capabilities of the IBM Thinkpads, even stronger case, but 1/4 the weight. Sadly, the Vaios didn't look professional enough (being targetted at multimedia applications) and didn't go over with Mohagony Row.
Now for one thing an IBM Laptop will never be able to compete with: Sleep Mode. Apples are EXTREMELY nice in this area. No one ever shuts down or reboots their machines. They just close them or reopen them, and they work flawlessly every time. Windows Laptops tend to have all kinds of issues with this.
The only glitches I still have are dock related. No hot or warm docking/undocking, CD drive accesses at only 4X (on the dock) and the USB ports on the dock don't work.
That's not such a good dock. I've used several docks (which all seem to have worked better than yours) and I can't say I've been impressed. They always seem to be more trouble than their worth. Now the Mac, I have everything build in, so I don't need to worry about having access to my CD Drive or USB ports. They're right there and convenient to use. (On the side, not the back.) Instead of docking, just plug in the monitor, keyboard, mouse, and power