Is that the case, or does NetWare run as an OS, directly on the hardware?
NetWare is an operating system and has nothing to do with Windows at all. Last time I used it, it did still require you to boot into MSDOS first, but once you ran its EXE, it kicked DOS out and completely took over. It used to be the most popular network operating system, but NT has pretty much killed it. It's still around though....
A lot of Linux programmers have little or no experience with other Unixes and so do all sorts of things specific to the Linux kernal.
Right, but that'd cause problems trying to port to any other *nix... the difficulty porting such programs isn't because OSX is "really really different" from Linux. I contend that if one writes a program that works on, say Linux and FreeBSD, it'll be trivial to port to OSX (barring the hardware stuff I mentioned). However, if one writes a program that's uses Linux-specific stuff, it'll be just as hard to port to OSX as it would be to port to FreeBSD, Solaris, or some other *nix.
Why do you think its taking the Fink guys so long to be able to port over all of say a debian distribution?
Lack of time and/or manpower?
FWIW, I've personally compiled ghostscript, screen, GMT, cronolog, readline, gettext, mplayer, SDL, lame, and netpbm on OSX without having to make any source code tweaks at all. A friend might've compiled Tomcat, although maybe he just installed the binary... not sure. Most of that stuff is in fink now, but much of it wasn't at the time I compiled them... since they didn't need any real porting work, I'm assuming they weren't in fink because nobody had gotten around to doing it yet, not because it was difficult to do. cronolog still isn't in fink yet, and as I mentioned, compiles straight out of the box..../configure && make -j2 and you're set.
1) anything that uses the/proc filesystem; which not a small number of apps.
I'm not a Linux user, and I have no idea what apps use the/proc filesystem, but it seems to me that anything that does is horribly unportable. If "not a small number of apps" require/proc, I'd say that the majority of those are poorly-written.
2) Any program that uses an assembly subroutine anywhere
Why can't OSX use assembly? If a program has some x86 assembly, sure, that'd be a problem, but not a OSX-specific one. You can't use x86 assembly on LinuxPPC either. An altivec-optimized assembly routine that decrypts RC5 works just as well on OSX, LinuxPPC, NetBSD, or AIX. See the distributed.net client source code for an example.
3) Any program that uses elf specific routines
Such as...? Again, if there are a significant number of apps that even care what your object format is, I'd say the majority of them are poorly-written. Emacs' lisp undumping business is the only thing I can think of (and emacs has already been ported to OSX and even comes installed in the base system). Whose bright idea was it to intentionally make emacs dump core and try to reconstruct an executable out of the core dump anyways? Oh, that's right... RMS. (Have you seen how many undump routines there are in the emacs source? Daaaamn... but I digress...)
4) Any program that uses a library which can't be ported
Sure, but seeing that I don't buy your points 1-3, I'd say that most libraries would be pretty easy to port:)
Actually, I'd say the main barrier to porting to OSX was that it doesn't use the X Window System for its GUI. But since X has been ported to it, that barrier's gone.
A problem that still exists is accessing hardware peripherals, such as playing sound, communicating with USB devices, or the low-level DVD access needed to play DVDs.
Porting to OSX can be highly non-trivial, but most of the time, it is trivial. I think more of the problem lies with developers who learned how to program on x86 Linux not knowing how to write portable code. Even spending some time trying to compile their code on other ports of Linux would help them--I've seen a lot of 64-bit-unclean code when trying to compile stuff on an Alpha (no, you can't cast a pointer to an int... why do you even want to?), and some code that assumes little-endian byte ordering too.
Sounds like you misunderstand moderation... you moderate posts, not people. His post is funny, so it should be modded as such. If he posts a troll, fine, mod it as troll. Seems like you're the slashbot, with your attitude of wanting to mod down anyone you disagree with or dislike.
If you really want to get down to the nits, download a FreeBSD project and then download Darwin. Do a file compare. It will be pretty clear then.
I realize this discussion is about the kernel, but I don't have time to download the FreeBSD or Darwin source right now... however, I do have a MacOS X 10.1.5 install here, and here are some possibly-interesting stats:
[greyfox:~] root# uname -a
Darwin greyfox.azeotrope.org 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc
[greyfox:~] root# grep -l FreeBSD/bin/*/sbin/*/usr/bin/*/usr/sbin/* | wc -l
14
[greyfox:~] root# grep -l NetBSD/bin/*/sbin/*/usr/bin/*/usr/sbin/* | wc -l
133
[greyfox:~] root# grep -l OpenBSD/bin/*/sbin/*/usr/bin/*/usr/sbin/* | wc -l
24
[greyfox:~] root# strings/mach_kernel | grep BSD
setconf: IOFindBSDRoot returned an error (%d);setting rootdevice to 'sd0a'.
BSD Name
IOKitBSDInit
IOBSD
BSD Major
BSD Minor
BSD root: %s
BSD Component Version 5.5:
In other words, the kernel itself has no $*BSD$ RCS ID strings in it at all. And of the binaries that come with the system, a large majority are actually from NetBSD, with OpenBSD second and FreeBSD last. As an example, these are the RCS ID strings in/bin/ls:
I first heard it when it was Eight Megabytes, rather than Eighty. (Althought it was past the time when 8MB was considered a huge amount of RAM... I was using SPARCstation 1+s with 12 to 16MB of RAM.)
Sure, you can turn off CSS, but what good does that do? It makes the player unable to play any discs that do use CSS (which is most of them). I think the goal is to maximize the number of discs you can play, not minimize.
The loopholes menu is more of a debug menu--just because you can change something in there doesn't mean that it's actually a good idea to do so.
Anyways, I have the same player too... got it at Circuit City a few years back, after it was mentioned here.
I have an AD-600A, and while the design of the thing isn't particularly pretty, the construction seems OK to me. Only problem I've had is that the S/PDIF output jack got yanked on too hard, and it lifted the PCB trace. A bit of solder and jumper wire fixed that up though.
I don't even think they all have optical audio out.
Why would you want optical outputs anyways? I've always found that optical stuff annoying; give me RCA jacks and 75 ohm coax instead. (Which is what the Apex AD-600A has for its digital audio out).
Timothy can't read Big5? What the heck is that supposed to mean? Big5 is a character coding, not a language. Can he read GuoBiao or something? If so, just click on the simplified graphics link at the top.
As for getting a non-graphical version, click the fanti or jianti links.
No, you didn't. If you did, you wouldn't have asked, "Is this the convention that MS got a booth in?"
They had the technologies listed, but they didn't tell whether or not people were openly mocking the poor saps who were supposed to man the booths.
See? You still haven't read the article:
Everything was normal and smooth at their booth, lots of people interested or simply curious.
So sad... all that effort into trying to appear on-topic, and you still didn't manage to get first post. Better luck next time! But when you get caught, don't lie about having read the article.
I'm not sure why they put the word "automatically" in there--I don't see how that would matter. So you have your keyring on a floppy... you get an encrypted email from someone, so you put your keyring in, key in your passphrase, and attempt to decrypt it. You get a garbled message. Continue with the rest of the steps outlined in the paper...
Sure sounds like a PGP flaw to me if they decided to change the OpenPGP standard to prevent this problem.
And starting with hot water doesn't really speed up the process much, not by more than a few seconds.
My cold tap water is about 85F (hey, it's Texas and about 100F outside:). My hot tap water is 115F. I don't think you're gonna be able to raise the temperature of a gallon of water 30 degrees in a few seconds using stuff in your kitchen:)
To do the math, lets say we want to raise the temperature of 4L of water by 17 degrees C. 4L water weighs 4kg, so it takes 4kcal to raise the temp by 1 degree C. To raise the temp by 17 degrees, that works out to be 68kcal, or about 284kilojoules of energy. To put that much energy into the water in 10 seconds requires 28.4kilowatts of power. Now say you have a 240 volt electric range... that means you'd be drawing 118 amps of current. You'd trip a circuit breaker or blow a fuse:) Most household electric ranges put out about 1500W or so per burner...
And of course, the problem gets worse if it's winter and the tap water is 40 degrees F or so.
Anyways, just trying it will show you that it makes more than a few seconds of difference. But personally, I always use cold water...
I could be talking out my ass on this, but I suspect that baking yeast is optimized for production of gas... while brewing yeast is optimized for producing alcohol....
I don't think you can optimize for one or the other... (at least if by "optimize" you mean producing more of one than the other). They come as a set:)
C6H12O6 -> 2 C2H5OH + 2 CO2
I.e. for every molecule of sucrose, you get 2 molecules of ethanol and 2 molecules of carbon dioxide.
I'll make a bet that the XP installs that Dell ships after the cutoff date won't need to be 'activated' through Microsoft, but will recognize the machine and bios as a 'licensed platform'.
Successfully implemented, SLP uses information stored in an OEM PC's BIOS to protect the installation from casual piracy. No communication by the end customer to Microsoft is required and no hardware hash is created or necessary. At boot, Windows XP compares the PC's BIOS to the SLP information. If it matches, no activation is required.
So is Alan Cox going to boycott EU conferences too? Are non-EU software engineers unsafe in EU nations? Maybe Alan needs to move to Taiwan or some place like that, where copyright laws are very lax. Or maybe he just needs to admit that his whole resignation deal was to push his political agenda (which is perfectly fine), not that he truly believed that he would be in danger if he came to the US.
Do you have a reference for this? The Wall Street Journal ran an article a year or so back where they investigated and concluded that the stack in Windows 2000 and XP is BSD-derived. Sadly, it's no longer available online.
Well, some guy on Kuro5hin wrote a rebuttal of that WSJ claim... maybe the guy's just making stuff up, but he says he worked at MS for 10 years, and knows the history of MS's TCP stack.
For one thing, he says that Spider Systems' stack was replaced by one written from scratch in NT 3.5 (which I assume means that Spider's stack was only in NT 3.1).
Now, he does say, "I won't even swear on a stack of bibles that the "new" TCP/IP now shipping in NT/2000/XP and Windows 95/98/Me is completely free of the old code from Spider," but even so, I really doubt if any actual BSD source code made it into Windows' TCP stack. I do think MS used BSD source as a reference to get the details on how things should work, which may explain the similarities and corner-case bugs. However, I don't think it'd be practical to actually lift the source code--the BSD and Windows kernel APIs just differ too much (heck, it's often not worth sharing source code between Linux and BSD drivers, and they're both Unixy... I know both sides look at the others' drivers for reference though). And it's my feeling that even Spider's stack was just based on Net/3; I don't think it contained much, if any, actual Net/3 source. After all, they did make the thing as a STREAMS module (according to the Kuro5hin guy), something pretty foreign to BSD.
But in the end, no, I don't have absolute proof that Windows' TCP stack doesn't have any BSD code in it. However, there's no proof that it does either, and it's annoying when people keep making the claim as if there were. Especially from what I know and what I've heard, I think it's more likely that there isn't any BSD code in there.
Slashdot Mirror
NetWare is an operating system and has nothing to do with Windows at all. Last time I used it, it did still require you to boot into MSDOS first, but once you ran its EXE, it kicked DOS out and completely took over. It used to be the most popular network operating system, but NT has pretty much killed it. It's still around though....
Well, they can, but they don't... which is fine too.
Right, but that'd cause problems trying to port to any other *nix... the difficulty porting such programs isn't because OSX is "really really different" from Linux. I contend that if one writes a program that works on, say Linux and FreeBSD, it'll be trivial to port to OSX (barring the hardware stuff I mentioned). However, if one writes a program that's uses Linux-specific stuff, it'll be just as hard to port to OSX as it would be to port to FreeBSD, Solaris, or some other *nix.
Why do you think its taking the Fink guys so long to be able to port over all of say a debian distribution?
Lack of time and/or manpower?
FWIW, I've personally compiled ghostscript, screen, GMT, cronolog, readline, gettext, mplayer, SDL, lame, and netpbm on OSX without having to make any source code tweaks at all. A friend might've compiled Tomcat, although maybe he just installed the binary... not sure. Most of that stuff is in fink now, but much of it wasn't at the time I compiled them... since they didn't need any real porting work, I'm assuming they weren't in fink because nobody had gotten around to doing it yet, not because it was difficult to do. cronolog still isn't in fink yet, and as I mentioned, compiles straight out of the box... ./configure && make -j2 and you're set.
I'm not a Linux user, and I have no idea what apps use the /proc filesystem, but it seems to me that anything that does is horribly unportable. If "not a small number of apps" require /proc, I'd say that the majority of those are poorly-written.
2) Any program that uses an assembly subroutine anywhere
Why can't OSX use assembly? If a program has some x86 assembly, sure, that'd be a problem, but not a OSX-specific one. You can't use x86 assembly on LinuxPPC either. An altivec-optimized assembly routine that decrypts RC5 works just as well on OSX, LinuxPPC, NetBSD, or AIX. See the distributed.net client source code for an example.
3) Any program that uses elf specific routines
Such as...? Again, if there are a significant number of apps that even care what your object format is, I'd say the majority of them are poorly-written. Emacs' lisp undumping business is the only thing I can think of (and emacs has already been ported to OSX and even comes installed in the base system). Whose bright idea was it to intentionally make emacs dump core and try to reconstruct an executable out of the core dump anyways? Oh, that's right... RMS. (Have you seen how many undump routines there are in the emacs source? Daaaamn... but I digress...)
4) Any program that uses a library which can't be ported
Sure, but seeing that I don't buy your points 1-3, I'd say that most libraries would be pretty easy to port :)
Actually, I'd say the main barrier to porting to OSX was that it doesn't use the X Window System for its GUI. But since X has been ported to it, that barrier's gone.
A problem that still exists is accessing hardware peripherals, such as playing sound, communicating with USB devices, or the low-level DVD access needed to play DVDs.
Porting to OSX can be highly non-trivial, but most of the time, it is trivial. I think more of the problem lies with developers who learned how to program on x86 Linux not knowing how to write portable code. Even spending some time trying to compile their code on other ports of Linux would help them--I've seen a lot of 64-bit-unclean code when trying to compile stuff on an Alpha (no, you can't cast a pointer to an int... why do you even want to?), and some code that assumes little-endian byte ordering too.
Sounds like you misunderstand moderation... you moderate posts, not people. His post is funny, so it should be modded as such. If he posts a troll, fine, mod it as troll. Seems like you're the slashbot, with your attitude of wanting to mod down anyone you disagree with or dislike.
Jell-O is a... gel. Which is liquid suspended in a solid matrix.
Heh, the editors have fixed the "3 sq/km," but as of this post, it still says, "100 sq/km coming soon."
I realize this discussion is about the kernel, but I don't have time to download the FreeBSD or Darwin source right now... however, I do have a MacOS X 10.1.5 install here, and here are some possibly-interesting stats:
[greyfox:~] root# uname -a /bin/* /sbin/* /usr/bin/* /usr/sbin/* | wc -l /bin/* /sbin/* /usr/bin/* /usr/sbin/* | wc -l /bin/* /sbin/* /usr/bin/* /usr/sbin/* | wc -l /mach_kernel | grep BSD
Darwin greyfox.azeotrope.org 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc
[greyfox:~] root# grep -l FreeBSD
14
[greyfox:~] root# grep -l NetBSD
133
[greyfox:~] root# grep -l OpenBSD
24
[greyfox:~] root# strings
setconf: IOFindBSDRoot returned an error (%d);setting rootdevice to 'sd0a'.
BSD Name
IOKitBSDInit
IOBSD
BSD Major
BSD Minor
BSD root: %s
BSD Component Version 5.5:
In other words, the kernel itself has no $*BSD$ RCS ID strings in it at all. And of the binaries that come with the system, a large majority are actually from NetBSD, with OpenBSD second and FreeBSD last. As an example, these are the RCS ID strings in /bin/ls:
/bin/ps is from FreeBSD though:I hope RMS isn't singing it...
I first heard it when it was Eight Megabytes, rather than Eighty. (Althought it was past the time when 8MB was considered a huge amount of RAM... I was using SPARCstation 1+s with 12 to 16MB of RAM.)
Sure, you can turn off CSS, but what good does that do? It makes the player unable to play any discs that do use CSS (which is most of them). I think the goal is to maximize the number of discs you can play, not minimize.
The loopholes menu is more of a debug menu--just because you can change something in there doesn't mean that it's actually a good idea to do so.
Anyways, I have the same player too... got it at Circuit City a few years back, after it was mentioned here.
I have an AD-600A, and while the design of the thing isn't particularly pretty, the construction seems OK to me. Only problem I've had is that the S/PDIF output jack got yanked on too hard, and it lifted the PCB trace. A bit of solder and jumper wire fixed that up though.
I don't even think they all have optical audio out.
Why would you want optical outputs anyways? I've always found that optical stuff annoying; give me RCA jacks and 75 ohm coax instead. (Which is what the Apex AD-600A has for its digital audio out).
As for getting a non-graphical version, click the fanti or jianti links.
No, you didn't. If you did, you wouldn't have asked, "Is this the convention that MS got a booth in?"
They had the technologies listed, but they didn't tell whether or not people were openly mocking the poor saps who were supposed to man the booths.
See? You still haven't read the article:
So sad... all that effort into trying to appear on-topic, and you still didn't manage to get first post. Better luck next time! But when you get caught, don't lie about having read the article.
Mozilla can do this too, with an add-in. Just download and install the Preferences Toolbar.
Would you also barcode each atom of the barcode sticker? If so, wouldn't it take an infinite number of barcodes to do the job? :)
Sure sounds like a PGP flaw to me if they decided to change the OpenPGP standard to prevent this problem.
My cold tap water is about 85F (hey, it's Texas and about 100F outside :). My hot tap water is 115F. I don't think you're gonna be able to raise the temperature of a gallon of water 30 degrees in a few seconds using stuff in your kitchen :)
To do the math, lets say we want to raise the temperature of 4L of water by 17 degrees C. 4L water weighs 4kg, so it takes 4kcal to raise the temp by 1 degree C. To raise the temp by 17 degrees, that works out to be 68kcal, or about 284kilojoules of energy. To put that much energy into the water in 10 seconds requires 28.4kilowatts of power. Now say you have a 240 volt electric range... that means you'd be drawing 118 amps of current. You'd trip a circuit breaker or blow a fuse :) Most household electric ranges put out about 1500W or so per burner...
And of course, the problem gets worse if it's winter and the tap water is 40 degrees F or so.
Anyways, just trying it will show you that it makes more than a few seconds of difference. But personally, I always use cold water...
(actually, I guess C6H12O6 is glucose... oops :)
I don't think you can optimize for one or the other... (at least if by "optimize" you mean producing more of one than the other). They come as a set :)
I.e. for every molecule of sucrose, you get 2 molecules of ethanol and 2 molecules of carbon dioxide.That's always been how it works, actually... the OEM installs of XP that come with Dells (and other big-name PC makers) do check the BIOS and don't require activation. See MS's "Technical Details on Microsoft Product Activation for Windows XP" (google's HTML version or the original Word doc):
My NOTEBOOK has higher resolution than that.
So is Alan Cox going to boycott EU conferences too? Are non-EU software engineers unsafe in EU nations? Maybe Alan needs to move to Taiwan or some place like that, where copyright laws are very lax. Or maybe he just needs to admit that his whole resignation deal was to push his political agenda (which is perfectly fine), not that he truly believed that he would be in danger if he came to the US.
Well, some guy on Kuro5hin wrote a rebuttal of that WSJ claim... maybe the guy's just making stuff up, but he says he worked at MS for 10 years, and knows the history of MS's TCP stack.
For one thing, he says that Spider Systems' stack was replaced by one written from scratch in NT 3.5 (which I assume means that Spider's stack was only in NT 3.1).
Now, he does say, "I won't even swear on a stack of bibles that the "new" TCP/IP now shipping in NT/2000/XP and Windows 95/98/Me is completely free of the old code from Spider," but even so, I really doubt if any actual BSD source code made it into Windows' TCP stack. I do think MS used BSD source as a reference to get the details on how things should work, which may explain the similarities and corner-case bugs. However, I don't think it'd be practical to actually lift the source code--the BSD and Windows kernel APIs just differ too much (heck, it's often not worth sharing source code between Linux and BSD drivers, and they're both Unixy... I know both sides look at the others' drivers for reference though). And it's my feeling that even Spider's stack was just based on Net/3; I don't think it contained much, if any, actual Net/3 source. After all, they did make the thing as a STREAMS module (according to the Kuro5hin guy), something pretty foreign to BSD.
But in the end, no, I don't have absolute proof that Windows' TCP stack doesn't have any BSD code in it. However, there's no proof that it does either, and it's annoying when people keep making the claim as if there were. Especially from what I know and what I've heard, I think it's more likely that there isn't any BSD code in there.
Whoops, I got the wrong units on the CVD diamond... the page says 2000 W/m-K, which would be 20 W/cm-K.