He had to kidnap the girl because a Commodore 64 does a really crappy job with porn. A decade ago, somebody should have given him a 386SX-16 with a Trident 1 MB SVGA card.
If the world revolved around cdrecord, Joerg might be right to chose naming that is the same across all platforms.
The consistency we want is consistency with all other apps on the platform. That means the/dev/* names on Linux, drive letters and NT-native object names on Windows, Mach IOKit names on MacOS X, and so on. The 1980s-style numbers are good for 1980s-style OSes like MS-DOS.
Ideally the command switches would start with "/" on MS-DOS, Windows, and OS/2.
He'd be in the clear if cdrecord were 100% his own work. If that were the case, then one might reasonably argue that he has implicitly granted an exception to the GPL and/or CDDL.
Problem for Joerg: he has included GPL work from other people. This puts Joerg in violation of the GPL.
That is an SRPM. Red Hat doesn't seem to provide binary RPM files for ES4. You should have an rpmbuild command that will build that into a regular rpm. The rpm command itself used to be able to build from source; probably the ability still exists in RHEL ES4.
Debian certainly provides sg_scan.
As for ifconfig: that is kind of obsolete now. It's a compatibility hack that uses a sort of BSD emulation layer. Getting to know the more-powerful native tools (the ip command) would be a good idea.
Plugging in a different burner gives you a result according to you udev config. I expect that the default behavior depends on your Linux distribution. One person may want the same name (the new burner is a replacement for one that broke) and another person wants a different name. No choice will please everybody. Probably somebody is writing a nice GUI config for this which will ask you what to do. Until then, you may need to adjust a config file to control what udev does for the naming.
Perhaps FC is just not good, the driver is incomplete, or nobody has written udev rules. FireWire and USB both cause hot-plug events when a new device is added. This triggers the creation of a file in/dev.
USB sticks can be trouble. In violation of the USB spec, they often lack unique serial numbers. You can certainly write your own naming routine, basing your names on filesystem content. SuSE failing to delete a directory is a bug of course. People who do the whole GUI thing (as is default) should get a filesystem browser to pop up when a USB stick is inserted.
Joerg avoids documenting the existance of support for device files. He threatens to remove it. Some of the support is not in Joerg's code anyway, but in patches that are applied by others. I'm not sure if dev=/dev/rcd0c works without OpenBSD patches, but in any case it is "not supported" by Joerg.
OpenBSD does a decent job of things. FreeBSD does not. Darwin is OK, though a bit odd: the real device names are neither SCSI nor/dev, but some sort of Mach-based IOKit namespace. I forget the status of NetBSD. Probably DragonflyBSD is as broken as FreeBSD.
Of course Linux uses/dev names. Most of the "real" UNIX systems use/dev names that just happen to resemble the old notation, which is OK. Windows uses drive letters which map to objects in the, uh, non-Win32 NT-native object space.
No matter the OS, people want to use the regular names. Joerg does that for MS-DOS, AmigaOS, various less popular things, and I suppose FreeBSD. I "suppose" because FreeBSD does have partially working names in/dev that could be mapped to -- the opposite of the mapping he performs on every modern OS.
Even on Solaris,/dev/c0b0t0l0 or/dev/c0b0t0 is what people expect. People don't want 0,0,0. The situation is somewhat tolerable there, because the translation can be done in your head. You can't tell that "/dev/Christmas present" on a Linux box is 0,1,0 unless you use -scanbus.
FreeBSD is the only major OS still in the dark about this. Systems that can address devices by name include Linux, Windows, MacOS X, AIX, IRIX, OpenBSD, and even Solaris. (Joerg lies about this: if you check the code, you can see that he works hard to emulate the old numbering on modern OSes) FreeBSD is in the company of AmigaOS, MS-DOS, Ultrix, etc.
For people with more than one burner, device names are far superior. When I plug in a couple USB drives, they can get useful names. FreeBSD uses 1,2,3 and 1,2,4 while Linux uses whatever the user likes:/dev/sony-dvd and/dev/lightscribe. Unplug the drives, and the Linux/dev files go away. (udevd deletes them) Plug them in again in different locations, and watch the/dev files come back: same name, same permissions, even if the device numbers change. On FreeBSD you can do the -scanbus thing, unplug and replug the burners, then burn the wrong CD because the ID numbers changed.
It's been a damn long time since I've needed to rescan a SCSI bus. (last time: a now-fixed driver bug) When I plug in a device, the/dev files appear automatically. Why does FreeBSD need this? Don't you support hot-plug?
There is nothing wrong with forking from an older version. Starting from scratch is usually stupid.
She is in control now, refusing to admit she lied. (she damn well knows she WILL face the music if she admits her lie today)
The DA is of course also in control. He is required to drop cases without merit. He has not done so, probably because of the protesters and the racially charged environment. (besides the gender issue, the local neighborhood wants to see a white well-off university student convicted for once)
He's not supposed to be paid to keep cases going without regard to merit.
He's supposed to drop cases that have no merit. This is required to keep our court system from being clogged up with nonsense, to avoid wasting money, and because it is unjust to force random people to need to defend themselves or plea-bargain over random nonsense.
I don't have access to much posting history. (didn't pay) I'm certainly not the only "r00t" on the net; I have no reason to believe "eviltypeguy" is unique either. Not even CmdrTaco is unique. Based on the English, I started to suspect that you might not be Joerg. About the only other person who agrees with Joerg is the xcdrecord author, so I figure that there is a good chance you wrote cdrecord.
But OK. I suppose I can believe Joerg has more than one fan. You're #2.
From personal experience, I know that taking over a project is quite a lot of work. (if you run Linux, you almost certainly run my code every day) Taking over a project involving lots of poorly-documented hardware is nearly insane. I've considered it though!
Lots of people have wanted to fork cdrecord. I pretty much did, but never made the first release. Cleaning up the crud would be horribly painful. Joerg has rolled many other projects into cdrecord, including mkisofs. So you can't just maintain the one program. If you drop the others, then you aren't providing a full replacement. Joerg keeps critical info in his head. The source does not include enough comments to tell why certain odd things are being done. You'd have to just make mistakes, pissing users off with ruined media. Since cdrecord does not provide a sane interface for wrapper programs, you have to maintain the old crap right down to the very last space character. You'd have to burn lots of media, which is like burning dollars. Grab a few dollars out of your wallet and set them on fire. Now do it again. Again, and again, and again...
Back in the 1980s, the SCSI command protocol and the old-style SCSI bus were a matched pair. Devices had ID numbers that you could set with jumpers. Devices didn't move around. There was no hot-plug or plug-and-play.
Now we run the SCSI protocol over USB, FireWire, SerialATA, TCP/IP, and numerous other transports. You can't address all the devices on the Internet with a 3-bit number. Devices come and go. If you plug in a CD burner, it usually shouldn't matter which USB port you use.
The Linux solution is UDEV. We can also use D-BUS and HAL. Device names in/dev are now set by the user. UDEV matches various things (serial number, manufacturer, location, etc.) to identify the device. Device numbers are dynamic and essentially random. The names are stable. Normal apps open devices by name.
Joerg wants to use an obsolete backdoor. He doesn't use the normal device names or the normal CD/DVD driver. He uses the/dev/sg* devices, which are intended for screwball devices that don't have normal drivers. It is similar to a modem program bypassing the/dev/tty* devices by calling iopl() and then directly controlling the hardware.
Suppose you have two USB burners. If you yank out your USB cable and then put it back, the device numbers may change. The device names can remain the same, thanks to UDEV. Joerg's defective program will be unaware of this. It will just use the wrong burner.
"If that's all it was, then why has no one else been able to create an equivalent tool to Joerg's?
You make it sound like Joerg was all hot air, and not a extremely technically cable person."
Who said anything about technical capability?
Well, I will: Joerg is moderately capable. His advantage is that he personally owns many expensive and out-of-production burners, and that his employer (the lovely MP3 patent holders) he has an unusual ability to get vendors to cooperate in giving out hardware information under NDA.
Joerg is a stubborn bone-headed idiot when it comes to user interface, hardware abstractions, and portability. He has the gall to claim that users actually like to specify all burners by a 1980s-style set of three numbers, and that users actually like running the -scanbus option instead of just using/dev/burner (or/dev/white-sony-drive, etc.) for the name. See the linux-kernel mailing list for some great flamewars, many involving Linus and many which lead to somebody catching Joerg in a lie.
So... are you Joerg, or are you his buddy the xcdroast author? That program too is a piece of shit. I've seen the code. It has buffer overflows. It doesn't abstract out the interface to the burner program. All over the code one can find ugly little bits of buggy cdrecord output parsing code, mixed right in with the GUI widgets. That's not how competant people write programs, excepting throw-away hacks.
Why so many cases all of a sudden? Isn't that just a bit suspicious?
I'm inclined to believe that the first case was real. (damn pervert, but hey, get a big enough group of people and you'll have perverts)
After that, no. These guys are innocent. There is absolutely no way they can defend themselves. Nobody has any real evidence. People are claiming stuff that happened many years ago. There is no hope of finding witnesses for the defense.
Fads come and go, even in fraud. Today the in thing to do is claim you've been molested by a priest. $$$$$$$$
He damn well does know what he is talking about. Check out the Duke University students accused of raping some lady. She's changed her story several times, there is no physical evidence, and she was with some other lady who wasn't out of sight for more than 15 minutes. The claim is that several students gang-raped her in every oriface. Eeeew. This happened in 15 minutes without leaving any physical evidence? Despite the absurdity of it all, the prosecuter still won't drop the case. He ought to put the lady on trial for false accusation, purgery, etc.
The feminists demand a conviction though, so the case goes on.
Come on now, seriously: this is just like any other fraud.
Let's sue somebody to get cold hard cash. Gee, the docter didn't make you perfect. That's malpractice, good for twenty million dollars. Oh, you slipped on the ice. Obviously the property owner is at fault, and you deserve ten million dollars. If you need a quick ten thousand dollars, fake a car accident. Want pity with your cash? Set up a cancer fund for yourself. You don't even need to get cancer. If female, you can accuse a few field hocky players of gang raping you in every oriface. Got a suit and tie? You could sue IBM for copying millions of lines of code from UNIX into Linux.
Sleazy lawyers and trashy clients will do as they do, same as always. Follow the money.
Slashdot Mirror
He had to kidnap the girl because a Commodore 64 does a really crappy job with porn.
A decade ago, somebody should have given him a 386SX-16 with a Trident 1 MB SVGA card.
"his thought processes are not standard issue"
Oh my. That is perfect.
If the world revolved around cdrecord, Joerg might be right to chose naming that is the same across all platforms.
/dev/* names on Linux, drive letters and NT-native object names on Windows, Mach IOKit names on MacOS X, and so on. The 1980s-style numbers are good for 1980s-style OSes like MS-DOS.
The consistency we want is consistency with all other apps on the platform. That means the
Ideally the command switches would start with "/" on MS-DOS, Windows, and OS/2.
Porting an app means adapting to the environment.
He'd be in the clear if cdrecord were 100% his own work. If that were the case, then one might reasonably argue that he has implicitly granted an exception to the GPL and/or CDDL.
Problem for Joerg: he has included GPL work from other people. This puts Joerg in violation of the GPL.
I think this is pretty much the file you forgot:
/ 4/en/os/i386/SRPMS/sg3_utils-1.06-3.src.rpm
http://ftp.redhat.com/pub/redhat/linux/enterprise
That is an SRPM. Red Hat doesn't seem to provide binary RPM files
for ES4. You should have an rpmbuild command that will build that
into a regular rpm. The rpm command itself used to be able to build
from source; probably the ability still exists in RHEL ES4.
Debian certainly provides sg_scan.
As for ifconfig: that is kind of obsolete now. It's a compatibility
hack that uses a sort of BSD emulation layer. Getting to know the
more-powerful native tools (the ip command) would be a good idea.
Plugging in a different burner gives you a result according to you udev config. I expect that the default behavior depends on your Linux distribution. One person may want the same name (the new burner is a replacement for one that broke) and another person wants a different name. No choice will please everybody. Probably somebody is writing a nice GUI config for this which will ask you what to do. Until then, you may need to adjust a config file to control what udev does for the naming.
/dev.
Perhaps FC is just not good, the driver is incomplete, or nobody has written udev rules. FireWire and USB both cause hot-plug events when a new device is added. This triggers the creation of a file in
USB sticks can be trouble. In violation of the USB spec, they often lack unique serial numbers. You can certainly write your own naming routine, basing your names on filesystem content. SuSE failing to delete a directory is a bug of course. People who do the whole GUI thing (as is default) should get a filesystem browser to pop up when a USB stick is inserted.
Joerg avoids documenting the existance of support for device files. He threatens to remove it. Some of the support is not in Joerg's code anyway, but in patches that are applied by others. I'm not sure if dev=/dev/rcd0c works without OpenBSD patches, but in any case it is "not supported" by Joerg.
/dev, but some sort of Mach-based IOKit namespace. I forget the status of NetBSD. Probably DragonflyBSD is as broken as FreeBSD.
/dev names. Most of the "real" UNIX systems use /dev names that just happen to resemble the old notation, which is OK. Windows uses drive letters which map to objects in the, uh, non-Win32 NT-native object space.
/dev that could be mapped to -- the opposite of the mapping he performs on every modern OS.
/dev/c0b0t0l0 or /dev/c0b0t0 is what people expect. People don't want 0,0,0. The situation is somewhat tolerable there, because the translation can be done in your head. You can't tell that "/dev/Christmas present" on a Linux box is 0,1,0 unless you use -scanbus.
OpenBSD does a decent job of things. FreeBSD does not. Darwin is OK, though a bit odd: the real device names are neither SCSI nor
Of course Linux uses
No matter the OS, people want to use the regular names. Joerg does that for MS-DOS, AmigaOS, various less popular things, and I suppose FreeBSD. I "suppose" because FreeBSD does have partially working names in
Even on Solaris,
Sure. He can do that. He has the right.
That's a very irritating decision though, especially when he refuses patches to add the missing feature.
It's Debian's right to decide Joerg can go to Hell.
FreeBSD is the only major OS still in the dark about this. Systems that can address devices by name include Linux, Windows, MacOS X, AIX, IRIX, OpenBSD, and even Solaris. (Joerg lies about this: if you check the code, you can see that he works hard to emulate the old numbering on modern OSes) FreeBSD is in the company of AmigaOS, MS-DOS, Ultrix, etc.
/dev/sony-dvd and /dev/lightscribe. Unplug the drives, and the Linux /dev files go away. (udevd deletes them) Plug them in again in different locations, and watch the /dev files come back: same name, same permissions, even if the device numbers change. On FreeBSD you can do the -scanbus thing, unplug and replug the burners, then burn the wrong CD because the ID numbers changed.
/dev files appear automatically. Why does FreeBSD need this? Don't you support hot-plug?
For people with more than one burner, device names are far superior. When I plug in a couple USB drives, they can get useful names. FreeBSD uses 1,2,3 and 1,2,4 while Linux uses whatever the user likes:
It's been a damn long time since I've needed to rescan a SCSI bus. (last time: a now-fixed driver bug) When I plug in a device, the
There is nothing wrong with forking from an older version. Starting from scratch is usually stupid.
She was in control when she claimed rape.
She is in control now, refusing to admit she lied. (she damn well knows she WILL face the music if she admits her lie today)
The DA is of course also in control. He is required to drop cases without merit. He has not done so, probably because of the protesters and the racially charged environment. (besides the gender issue, the local neighborhood wants to see a white well-off university student convicted for once)
He's not supposed to be paid to keep cases going without regard to merit.
He's supposed to drop cases that have no merit. This is required to keep our court system from being clogged up with nonsense, to avoid wasting money, and because it is unjust to force random people to need to defend themselves or plea-bargain over random nonsense.
I don't have access to much posting history. (didn't pay) I'm certainly not the only "r00t" on the net; I have no reason to believe "eviltypeguy" is unique either. Not even CmdrTaco is unique. Based on the English, I started to suspect that you might not be Joerg. About the only other person who agrees with Joerg is the xcdrecord author, so I figure that there is a good chance you wrote cdrecord.
But OK. I suppose I can believe Joerg has more than one fan. You're #2.
From personal experience, I know that taking over a project is quite a lot of work. (if you run Linux, you almost certainly run my code every day) Taking over a project involving lots of poorly-documented hardware is nearly insane. I've considered it though!
Lots of people have wanted to fork cdrecord. I pretty much did, but never made the first release. Cleaning up the crud would be horribly painful. Joerg has rolled many other projects into cdrecord, including mkisofs. So you can't just maintain the one program. If you drop the others, then you aren't providing a full replacement. Joerg keeps critical info in his head. The source does not include enough comments to tell why certain odd things are being done. You'd have to just make mistakes, pissing users off with ruined media. Since cdrecord does not provide a sane interface for wrapper programs, you have to maintain the old crap right down to the very last space character. You'd have to burn lots of media, which is like burning dollars. Grab a few dollars out of your wallet and set them on fire. Now do it again. Again, and again, and again...
Go to his own site. See him selling the full version. The version with source code is crippled. He left out the DVD code.
In other words, it's a crippleware trial version.
Back in the 1980s, the SCSI command protocol and the old-style SCSI bus were a matched pair. Devices had ID numbers that you could set with jumpers. Devices didn't move around. There was no hot-plug or plug-and-play.
/dev are now set by the user. UDEV matches various things (serial number, manufacturer, location, etc.) to identify the device. Device numbers are dynamic and essentially random. The names are stable. Normal apps open devices by name.
/dev/sg* devices, which are intended for screwball devices that don't have normal drivers. It is similar to a modem program bypassing the /dev/tty* devices by calling iopl() and then directly controlling the hardware.
Now we run the SCSI protocol over USB, FireWire, SerialATA, TCP/IP, and numerous other transports. You can't address all the devices on the Internet with a 3-bit number. Devices come and go. If you plug in a CD burner, it usually shouldn't matter which USB port you use.
The Linux solution is UDEV. We can also use D-BUS and HAL. Device names in
Joerg wants to use an obsolete backdoor. He doesn't use the normal device names or the normal CD/DVD driver. He uses the
Suppose you have two USB burners. If you yank out your USB cable and then put it back, the device numbers may change. The device names can remain the same, thanks to UDEV. Joerg's defective program will be unaware of this. It will just use the wrong burner.
Well yes, but you have to burn him first and he's on device 6,6,6.
Debian can choose whatever licenses are acceptable to release code under. Jorg can go screw himself.
For numerous unrelated reasons, a fork has been sorely needed. The license mess just makes it easier to get everyone to go for it. Thanks Jorg!
Who said anything about technical capability?
Well, I will: Joerg is moderately capable. His advantage is that he personally owns many expensive and out-of-production burners, and that his employer (the lovely MP3 patent holders) he has an unusual ability to get vendors to cooperate in giving out hardware information under NDA.
Joerg is a stubborn bone-headed idiot when it comes to user interface, hardware abstractions, and portability. He has the gall to claim that users actually like to specify all burners by a 1980s-style set of three numbers, and that users actually like running the -scanbus option instead of just using /dev/burner (or /dev/white-sony-drive, etc.) for the name. See the linux-kernel mailing list for some great flamewars, many involving Linus and many which lead to somebody catching Joerg in a lie.
So... are you Joerg, or are you his buddy the xcdroast author? That program too is a piece of shit. I've seen the code. It has buffer overflows. It doesn't abstract out the interface to the burner program. All over the code one can find ugly little bits of buggy cdrecord output parsing code, mixed right in with the GUI widgets. That's not how competant people write programs, excepting throw-away hacks.
Why should we believe you, eviltypeguy? Dude, you're an eviltypeguy.
(probably Jorg in fact)
Oh?
Why so many cases all of a sudden? Isn't that just a bit suspicious?
I'm inclined to believe that the first case was real. (damn pervert,
but hey, get a big enough group of people and you'll have perverts)
After that, no. These guys are innocent. There is absolutely no
way they can defend themselves. Nobody has any real evidence.
People are claiming stuff that happened many years ago. There
is no hope of finding witnesses for the defense.
Fads come and go, even in fraud. Today the in thing to
do is claim you've been molested by a priest. $$$$$$$$
He damn well does know what he is talking about. Check out the Duke University students accused of raping some lady. She's changed her story several times, there is no physical evidence, and she was with some other lady who wasn't out of sight for more than 15 minutes. The claim is that several students gang-raped her in every oriface. Eeeew. This happened in 15 minutes without leaving any physical evidence? Despite the absurdity of it all, the prosecuter still won't drop the case. He ought to put the lady on trial for false accusation, purgery, etc.
The feminists demand a conviction though, so the case goes on.
Lots of the serious perverts like little boys. Some of them probably think you're a cutie.
also:
criminal-victim relationship was stranger/family/other
victim was male/female
victim was N years old
victim was real or statuatory
Come on now, seriously: this is just like any other fraud.
Let's sue somebody to get cold hard cash. Gee, the docter didn't make you perfect. That's malpractice, good for twenty million dollars. Oh, you slipped on the ice. Obviously the property owner is at fault, and you deserve ten million dollars. If you need a quick ten thousand dollars, fake a car accident. Want pity with your cash? Set up a cancer fund for yourself. You don't even need to get cancer. If female, you can accuse a few field hocky players of gang raping you in every oriface. Got a suit and tie? You could sue IBM for copying millions of lines of code from UNIX into Linux.
Sleazy lawyers and trashy clients will do as they do, same as always. Follow the money.
So, to go to the next image, either:
a. you get a match
b. both you and your partner click pass
Yes? So if the other person keeps trying keywords that don't match, you're stuck for the 90 seconds?
My experience: One time I saw two images. (text, then a helmet) The other time I got the broken image icon.
The task I'm thinking of is not number crunching, so it works out.
(start an app, wait until the app is fully started and idle, examine the app and OS state, kill the app, repeat)
Remember the cost of air conditioning too.