the odds were not, in the absense of all other evidence, 1:50,000 against Larry murdering Curly, the odds were actually 100:1 that he didn't do it.
That's not true. In your hypothetical situation, there are (approximately) 100 matches in the city, but only one whom the police suspected enough check his DNA. The match wasn't how they found Larry, it was how they validated their suspicions. It would be closer to true had they run a DNA match against the entire population of the city, but that's not what you described. (And we don't have a system in place to do that sort of thing, so there aren't any real cases like that now.) There's no magic formula for finding the odds someone committed a crime, but your 100:1 is insane.
Not knowing these benchmarks were available, I just spent today compiling 2.4.6-smp for my Dual 500 MHz G4 PowerMac. My complete kernel rebuild time, using 4 jobs, was 3min,10sec, putting it ahead of the Dual-PIII/1GHz but behind the Dual Athlon/1.2GHz. I was very pleased with this speed.
Your point of comparison is pretty much worthless. The point of benchmarking is you do the same task on different hardware. You compiled a different version of the kernel. You couldn't have possibly had even remotely similar options because you didn't compile the arch/i386 directory and did compile the arch/ppc directory. For the architecture-independent options, you don't know what they compiled in (I didn't see it on their page). Their numbers are only useful relative to each other. I could take Linux 2.4.6 and compile it with the bare minimum of drivers and filesystems and finish in less time than any of their machines. It wouldn't mean anything.
Not really, there isn't a standard socket API for C or C++, strictly speaking, in the sense that sockets are not part of either language. Because of this, C++/C programming books are not going to teach him anything useful about sockets, he really needs a UNIX programming book.
Hmm, you're right. It's easy for me to forget that just because the C stuff is common on many platforms, it isn't going to be in the same book. There is a lot more stuff about it than C++, but not as integrated as Java.
But that doesn't really take away from the point of my post - that API-wise, Java is much easier. This is true for Perl and Python as well, but Perl can teach some really bad habits and Python isn't as widely spoken.
As for learning OO in java, one of the messy things about java is that it makes proceedural programming very awkward. I also found its object model confusing when I started out. For example, why is main static (as opposed to, say, eiffel, where you run the program by instantiating an application ?) Those words "public static void main are a tad intimidating, especially when you're reading a book that doesn't even explain what these mean until 500pages or so in.
True as well. But I still think Java would be an easier language to learn for this AC since it sounds like he would have a much easier time if he could get into some practical code and have one book that would cover a pretty broad range of API stuff.
I'd love to learn to program with sockets, even maybe some X apps or somtehing of the similar, but I don't see that much documentation (well, that's easy to understand and findable) anywhere. [...] I've done this multiple time over the years, but I guess I might not be cut out for programinng
It's not you. You're absolutely right that there isn't much C++ documentation out there that is easy to understand.
A big part of the reason none of the C++ books you've found talk about socket programming is there is no C++ socket API. There is a fairly standard C socket API (standard across UNIX systems, anyway) and all C code is callable from C++. So, theoretically there is everything you need to do socket programming, it just isn't as easy as you might like. A lot of people have tried to solve this by creating wrapper classes (a class that is intended to repackage existing code into an easier form) but for the most part, each do a fairly subset of what any program needs to do and don't fit together with each other very well.
There are a few exceptions. TrollTech has done a good job of creating a cross-platform C++ API with Qt. And KDE builds on that further. So if seeing practical examples would help you out, maybe you should jump right in to something more specific to Qt and KDE. I don't think there's much stuff out there introducing Qt and KDE to C++ beginners though, so you will still need to refer to another C++ book.
Another alternative would be to learn OO stuff with Java. Java has been criticized a lot for its speed, but I don't remember anyone who says it doesn't have a good API. There are lots and lots of existing classes to help you write useful code right away. It is all well-documented...plenty of books on Java, and they all describe the API as well as the language, unlike most C++ books. Sun has a really nice tool, javadoc for creating reference documentation as well. Just about any Java package, whether one from Sun or elsewhere, will have nice documentation in the same format. And there are tutorial's available on Sun's website.
There are a few problems with learning Java first. The one that comes to mind right now is garbage collection. This is a nice feature because you don't have to write specific code to handle memory deallocation. This is a terrible feature for a learning language because you don't have to know anything about memory deallocation. Some people who learn Java first write some pretty terrible code memory-wise when they switch to C++, and this is why. Still, in your case I'd say that learning Java is probably the best option.
If you ask me, identd is nothing more than a waste of bandwidth. Someone, please prove me wrong.
ident is useful because it allows you to ask a trusted computer which of its users is making a connection. As a practical example, I use ident to authenticate users to PostgreSQL databases.
The details: my system uses Apache's SUEXEC to run different virtual hosts under different UNIX users. Since the information from identd can be relied on (it's trusted since it's localhost and fakeid support is turned off) I use pg_hba.conf and pg_ident.conf to configure what UNIX users can connect to what databases as what PostgreSQL users. Then end effect is, I don't have to embed passwords in my CGIs where I would have to otherwise. I could even seperate the SQL server to a different machine and still not have to specify passwords, as long as SQL machine trusts the webserver (it would, since I would own them both) and the network between (I would have them on the same subnet).
Create a "Follow-ups" category, and post any story directly related to any "recent" (say, 3 months?) story under this category. People can then choose to ignore that category, if they like. - dschuetz
Back in the Sixties I had a weather changing
machine that was in essence a sophisticated heat beam which we called a
"laser." Using this laser, we punch a hole in the protective layer around
the Earth, which we scientists call the "Ozone Layer." Slowly but surely,
ultraviolet rays would pour in, increasing the risk of skin cancer. That
is, unless the world pays us a hefty ransom. - Dr. Evil, Austin Powers
Okay, the point is, both of these things have already happened. There is a Slashback category for this purpose. It just doesn't get used all the time.
Re:Spam is an ISP's headache
on
ORBS Forks
·
· Score: 2
A responsible and level-headed version of ORBS is very possible and quite welcome to me.
RSS has the same stated goal as ORBS - to allow people to block open relays if they so choose. But RSS is run by different people and is run much more responsibly. They do not probe IP blocks looking for open relays. They wait until someone submits a piece of spam with full headers. Then they check the relay listed in the spam to see if it is indeed open. If so, a human looks at it and blocks it. Once the open relay has corrected the problem, the RSS people take them off the list.
I believe ORBS also blocks anyone who does not allow their probing. RSS is blocked by ORBS, for example. I've also heard people say that it is very hard to get off the ORBS list. None of this is true of RSS.
I don't understand why people keep saying that the other browsers on Linux are still not "quite ready to take over for Netscape 4.77". Moz and Konq are both great, and have a somewhat different set of bugs. If a site is unusable on one I go to the other and it generally works great.
Because those freaks expect a single piece of software to accomplish a single task. They don't want to have to try one and switch when they encounter a bug, then back when they encounter another.
Realistically, I'm not satisfied with any of the browsers available for Linux. At the moment, I'm using Mozilla. This latest version is the first to seem fairly stable to me (meaning it crashes infrequently, not that it doesn't crash). But no matter what everyone says, it still is slow. When I click the back button in IE, I see the previous page at my previous location within the page. On Mozilla, I see it load the top of the previous page, pop in some of the images (seems like really small images don't cache or something, not quite sure) and reflow to fit them, then move to the previous location. All sorts of stuff that just makes it go slower and feel even slower.
Someone will reply about how the latest nightly build is better. It's inevitable; it always happens when talking about Mozilla. It's not fucking true. CVS versions of anything are not known for stability. Developers break things between releases. It's expected. If they didn't, the software wouldn't improve.
It bugs me when something is plugged for many different operating systems when I (admittedly not a coder, but I'm not totally clueless) can't compile it for the life of me on a recent stable FreeBSD release. This might not be such a problem if there was any kind of documentation, of any sort, anywhere, regarding other operating systems.
They aren't plugging it for many different operating systems. For each of their ports, they have a brief description of what is working and what isn't. In some cases, some pretty vital features are missing, and they aren't hiding that. VLC ports: BeOS,
BSD,
Linux,
MacOS X, QNX RTOS, Solaris, and Windows. Click on any of those to get the current status of the port. In the case of BSD, it says encrypted DVD input is untested. So you've got a pretty limited selection of DVDs you can get to work, unless someone has managed to get that code working (it is possible they just haven't updated that page).
You're missing the point. This isn't "wow, the VideoLAN team managed to crack CSS with a cryptic ninety-line Perl script that you pipe from/dev/dvd into/tmp/obscenelylargefile." This is "wow, the VideoLAN team managed to create a portable, simple, well-documented CSS decryption library that lets you access the DVD as a block device without even caring if it's encrypted."
Yes, the fact that CSS can be cracked is old news. The fact that there's a very high-quality library to do so is not.
Remember that for standard use, Tux would only serve static content - this drastically reduces the possibilities for attacks against it.
But doesn't reduce the possibilities for attacks against your system, which is a better goal. You still need Apache around for CGI access. Now you potentially have very dangerous vulnerabilities in Tux running as worse-than-root in addition to your normal Apache vulnerabilities. I don't see that as reducing the possibilities of attack.
The article quoted Tux's creator as saying on linux-kernel that "there is nothing significant left in [Tux] that cannot be done from user space." I think this means that it's time for Tux to die off. It was a great tool for the kernel developers to increase speed in the kernel. Now it's done its job...hopefully soon someone will release a full-featured high-performance webserver that runs in userspace. (Not like Tux and X-15, one that actually handles dynamic content on its own.) Apache 2.0 might qualify, but I'm crossing my fingers.
They return an argument, but it is not dynamically allocated. Calling free() on it would be a bad idea. Advantage: callers don't need to worry about calling free(). Disadvantages: they need to duplicate it if they want it to be valid after the next call to the same function. You need to use a thread-specific data key to be safe in threads.
In fact, the only standard C function I can think of at the moment that returns something it malloc()s is strdup() (well, aside from malloc()/calloc()/realloc() themselves, of course).
On the whiteboard I would forgive simple syntax mistakes and the like. There don't need to be any function calls (a lot of people call strlen, which is fine, but not needed).
Remarkably few made one pass over the string to find the length, and then a single extra pass to do the reverse. Those are the people I was looking for:-)
I think the real problem is that you didn't know good code when you saw it. The best people were not the ones who looped over the string to find the length, but the ones who called strlen(). As the AC just said, strlen() is optimized, written in assembler. Plus, hat loop is just slightly harder to read than strlen(str) and a typo could cause a bug. This is much more true with more complicated functions. Use the existing stuff unless you've got a good reason not to. The standard C library functions are well-written and well-tested.
Otherwise, you've got what seem to me to be good ideas about interviewing. But you've made what seems a dangerous assumption to me - that there's one correct solution to the problem, and it's that one. I would say some of those people had better solutions, though I would still consider your way acceptable.
That wasn't updated. It's been in use since before 4.1-RELEASE. It was finally included (after
years of testing) in OpenBSD 2.9. It's say it's pretty much a proven implementation at this point.
Thanks for the correction. I may be enabling it on my machine soon, then.
It's clear from their comments that they did not turn on Softupdates on the filesystems when they
set up their FreeBSD machine for the testing.
Isn't soft update still in testing? My FreeBSD 4.2-RELEASE system says this in/usr/src/sys/ufs/ffs/README:
This package constitutes the alpha distribution of the soft update
code updates for the fast filesystem.
I don't see anything to support the idea that this changed in 4.3. In particular, I don't see any mention of soft updates at all in the 4.3 handbook. I'd expect to if it were a completed feature.
Obviously this "test" is a crock, as FreeBSD would not be that far behind, what with it's surperior
network stack and thread handling.
This sounds very much to me like "I found this benchmark's results surprising, therefore I rejected them." You've given absolutely no evidence to support your claim that FreeBSD's network stack and thread handling are superior. You've said nothing about what mistakes may have caused their benchmarks to be skewed. If you are going to reject results you don't expect, what's the point of running the test?
I am not biased. I have all of these operating systems installed on my machines. The desktop I am at now is running Linux 2.4 and also has a copy of Windows 2000 installed. My colocated server is running FreeBSD. The old SPARCstation in the basement has Solaris (though, admittedly, I don't really use it).
It may be true that this is a very bad benchmark...but don't reject the results simply because they surprise you. Look into it...what was wrong with their test procedure? Without an answer to that, you have no credibility.
as opposed to the hashes unix keeps in/etc/passwd, which usually 33% can be obtained within hours, half within days?
I don't believe you. Prove it. Here's something I pulled at random from/etc/shadow. I don't know what this password is; obviously, I can check any answer you give me. It was chosen by someone who is not particularly security-conscious. I challenge you to break it: $1$s3m2axu1$QqizKegYZh5JLyXaCi/47.
Frank Poole is what I call a 90 percent anagram. The last 9 of the 10 letters of "[F]rank Poole" can be rearranged to form "[W]alk on Rope." I figured that one out by starting out with the knowledge that Frank Poole symbolized the rope dancer. Then I looked for phrases like "Rope Dancer," "Rope Walker," "Dance on Rope," and "Walk on Rope."
Here the author is committing a logical fallacy called the Texas Sharpshooter. A very short description of this fallacy: it is when you know the result before you begin the search for evidence. You then find evidence which matches your result, interpreting it favorably toward that result.
This fallacy got its name with a story. A man wants to prove he is a great sharpshooter, so he shoots at the unpainted side of the barn. He then draws a target around the bullethole. It is meaningless because the order is important. The target must be drawn before the bullet is fired, or the evidence must be gathered before the result is found.
Try something. Pick some element of mythology...any element of mythology. Think of short phrases that are related to it in some way. Then look 2001 (or any book/movie/play/whatever) for at least one of those phrases. You will find it. There are lots of anagrams of the character's names already without doing weird substitutions like cutting out the first letter of his name (why?!?) or changing "1" to "ONE". By the time you get to doing something like that, you are certain to find what you are looking for.
This proves nothing. You can say "[phrase]" is present, therefore [predecided conclusion]. That does not make it so.
(Disclaimer: I have not read the book. What I am saying here is based only on the review and the rebuttal.)
If you want to do something for the open source community right now, the last thing you would want to do is write another OS.
I hate to burst your bubble, but "do[ing] something for the open-source community" is not the primary goal of a lot of developers. They develop these projects because they learn something from them and they are fun. Helping out the open-source community is a bonus.
I quote the NewOS page:
NewOS exists to explore some aspects of modern OS design, and to have fun in the process. Also, I seemed to have collected a bunch of old non-x86 machines that need something running on them. I figure, "Hey, why dont I just port my OS over?" The rest is history.
If you really want to help the open-source community, stop posting to Slashdot and write good code. (And no, I'm not being a hypocrite here. I've never said it is my life's goal to contribute a great work to the open-source community. What code I write I do for the same reason this guy does. I/when I release any code, it won't be code I've written for the sole purpose of releasing.)
For the record, the definition is int getc(FILE *stream);
Not true. The definition is whatever Travis Geiselbrecht made it. You would have to look at the source code to know. This is not something that has to comply with ISO C, since it is in the kernel. In fact, it couldn't really comply to it...the userspace concept of a file descriptor in the FILE* structure doesn't really make sense, since each process's file descriptor table is distinct. The kernel deals with all of these, so a file descriptor alone doesn't uniquely identify anything. Without looking at the source code, I would guess the prototype he gave was char getc (void). It probably only deals with the console.
Look a little further up. The for loop with the getc() has no terminating clause and no break. So, with what we see here, this code would never be executed. The original poster is not quite correct, though, that this theoretically never will be executed. This is not the only thread running. Another thread could manipulate the instruction pointer and make that code execute. In my uneducated opinion (I know nothing of OS design), that would be dumb. I think the "Booyah!" bit is just code he no longer uses and didn't even bother to comment out.
I imagine sys_snooze(10^6) is a one-second sleep, not a million-second sleep. Without looking at the code for sys_snooze (I'm lazy), I'd guess it accepts microseconds, not seconds.
Keep in mind that in the kernel, none of the functions here are the ones defined by the libc...they are all for the kernel solely. The sys_snooze() is not the sleep() you know and love. The printf() and getc() are probably unbuffered. Someone else mentioned that this is sloppy code because getc() returns an int, not a char. You can't say that without looking at the getc() definition in the source, since it is not the POSIX getc.
Come on, you think the slashdot editors were too stupid to read this article before posting it?
Yes, I do. They have made progress toward real journalism. But this is incredibly sporadic. I think in this case Morgan read a tiny snippet of that FAQ, enough to see they would not boot from existing partitions. I think he did not read enough to realize that this was for a good reason, that the new standard is open, or that it only affects the 64-bit platform. I think Cliff read Morgan's submission only and didn't even look at the link.
Looking at the FAQ page linked to, I think this is a false alarm. Microsoft has several legitimate reasons for introducing this new partitioning scheme. It is an open standard; they link to the definition here.
It looks like a lot of the reason they are doing this is support for larger systems and disks. See these Q/As:
Q: If the disk is larger than the maximum size an MBR can report, will the entire disk contents be protected?
A:The EE partition in the Protective MBR is specified to be the maximum size allowable in an MBR.
So the maximum size supported by the new format is greater than the old.
Q: Can the 32-bit version of Windows Whistler read, write, and boot from GPT disks?
A: No. The 32-bit version will see only the Protective MBR. The EE partition will not be mounted or otherwise exposed to application software.
This doesn't affect your current system at all. If you install Windows Whistler on your ia32 machine, it will use the old format.
Linux already has the support for many different partitioning schemes. I don't see this as different. There is no support for it now, but there will be when someone decides to develop it.
[Reposting with my login name. Didn't notice I wasn't logged in, and would prefer this comment actually gets read.]
So, protest with your dollars. Capitalism is a beautiful thing. You always have the option of taking your money somewhere else. If they can squeeze more cash out of you because you're unwilling to do your own due dilligence, then too bad. If they want to charge you $500 more than some other vendor because you told them (or they somehow figured out) that you make more than $75k a year, go somewhere else. If enough customers balk at the practice of dynamic pricing, IBM/Compaq/Dell will end up losing money, so it will make more financial sense not to do it.
Did you read the post you were replying to? Did you read the article? As BradleyUffner pointed out, the article says that these are based on market-wide supply and demand. His point was that IBM and Compaq's dynamic pricing is different from Amazon's in that what you are talking about doesn't happen. They don't change the price based on your income or anything else about you. Any two people loading the page at the same time get a different price.
[ Full disclosure: I work for a company that writes software to support "dynamic pricing" on web sites. ]
The site you work on may do the things you talk about, but unless the article is a complete lie, this site doesn't. Don't assume that IBM's pricing system is like yours.
Slashdot Mirror
the odds were not, in the absense of all other evidence, 1:50,000 against Larry murdering Curly, the odds were actually 100:1 that he didn't do it.
That's not true. In your hypothetical situation, there are (approximately) 100 matches in the city, but only one whom the police suspected enough check his DNA. The match wasn't how they found Larry, it was how they validated their suspicions. It would be closer to true had they run a DNA match against the entire population of the city, but that's not what you described. (And we don't have a system in place to do that sort of thing, so there aren't any real cases like that now.) There's no magic formula for finding the odds someone committed a crime, but your 100:1 is insane.
Not knowing these benchmarks were available, I just spent today compiling 2.4.6-smp for my Dual 500 MHz G4 PowerMac. My complete kernel rebuild time, using 4 jobs, was 3min,10sec, putting it ahead of the Dual-PIII/1GHz but behind the Dual Athlon/1.2GHz. I was very pleased with this speed.
Your point of comparison is pretty much worthless. The point of benchmarking is you do the same task on different hardware. You compiled a different version of the kernel. You couldn't have possibly had even remotely similar options because you didn't compile the arch/i386 directory and did compile the arch/ppc directory. For the architecture-independent options, you don't know what they compiled in (I didn't see it on their page). Their numbers are only useful relative to each other. I could take Linux 2.4.6 and compile it with the bare minimum of drivers and filesystems and finish in less time than any of their machines. It wouldn't mean anything.
Not really, there isn't a standard socket API for C or C++, strictly speaking, in the sense that sockets are not part of either language. Because of this, C++/C programming books are not going to teach him anything useful about sockets, he really needs a UNIX programming book.
Hmm, you're right. It's easy for me to forget that just because the C stuff is common on many platforms, it isn't going to be in the same book. There is a lot more stuff about it than C++, but not as integrated as Java.
But that doesn't really take away from the point of my post - that API-wise, Java is much easier. This is true for Perl and Python as well, but Perl can teach some really bad habits and Python isn't as widely spoken.
As for learning OO in java, one of the messy things about java is that it makes proceedural programming very awkward. I also found its object model confusing when I started out. For example, why is main static (as opposed to, say, eiffel, where you run the program by instantiating an application ?) Those words "public static void main are a tad intimidating, especially when you're reading a book that doesn't even explain what these mean until 500pages or so in.
True as well. But I still think Java would be an easier language to learn for this AC since it sounds like he would have a much easier time if he could get into some practical code and have one book that would cover a pretty broad range of API stuff.
I'd love to learn to program with sockets, even maybe some X apps or somtehing of the similar, but I don't see that much documentation (well, that's easy to understand and findable) anywhere. [...] I've done this multiple time over the years, but I guess I might not be cut out for programinng
It's not you. You're absolutely right that there isn't much C++ documentation out there that is easy to understand.
A big part of the reason none of the C++ books you've found talk about socket programming is there is no C++ socket API. There is a fairly standard C socket API (standard across UNIX systems, anyway) and all C code is callable from C++. So, theoretically there is everything you need to do socket programming, it just isn't as easy as you might like. A lot of people have tried to solve this by creating wrapper classes (a class that is intended to repackage existing code into an easier form) but for the most part, each do a fairly subset of what any program needs to do and don't fit together with each other very well.
There are a few exceptions. TrollTech has done a good job of creating a cross-platform C++ API with Qt. And KDE builds on that further. So if seeing practical examples would help you out, maybe you should jump right in to something more specific to Qt and KDE. I don't think there's much stuff out there introducing Qt and KDE to C++ beginners though, so you will still need to refer to another C++ book.
Another alternative would be to learn OO stuff with Java. Java has been criticized a lot for its speed, but I don't remember anyone who says it doesn't have a good API. There are lots and lots of existing classes to help you write useful code right away. It is all well-documented...plenty of books on Java, and they all describe the API as well as the language, unlike most C++ books. Sun has a really nice tool, javadoc for creating reference documentation as well. Just about any Java package, whether one from Sun or elsewhere, will have nice documentation in the same format. And there are tutorial's available on Sun's website.
There are a few problems with learning Java first. The one that comes to mind right now is garbage collection. This is a nice feature because you don't have to write specific code to handle memory deallocation. This is a terrible feature for a learning language because you don't have to know anything about memory deallocation. Some people who learn Java first write some pretty terrible code memory-wise when they switch to C++, and this is why. Still, in your case I'd say that learning Java is probably the best option.
Other free countries have their days of independance [...] September 16th for Mexico (although I'll admit I had to look that one up)
That doesn't sound right to me. Isn't it cinco de mayo (May 5th)?
If you ask me, identd is nothing more than a waste of bandwidth. Someone, please prove me wrong.
ident is useful because it allows you to ask a trusted computer which of its users is making a connection. As a practical example, I use ident to authenticate users to PostgreSQL databases.
The details: my system uses Apache's SUEXEC to run different virtual hosts under different UNIX users. Since the information from identd can be relied on (it's trusted since it's localhost and fakeid support is turned off) I use pg_hba.conf and pg_ident.conf to configure what UNIX users can connect to what databases as what PostgreSQL users. Then end effect is, I don't have to embed passwords in my CGIs where I would have to otherwise. I could even seperate the SQL server to a different machine and still not have to specify passwords, as long as SQL machine trusts the webserver (it would, since I would own them both) and the network between (I would have them on the same subnet).
Create a "Follow-ups" category, and post any story directly related to any "recent" (say, 3 months?) story under this category. People can then choose to ignore that category, if they like. - dschuetz
Back in the Sixties I had a weather changing machine that was in essence a sophisticated heat beam which we called a "laser." Using this laser, we punch a hole in the protective layer around the Earth, which we scientists call the "Ozone Layer." Slowly but surely, ultraviolet rays would pour in, increasing the risk of skin cancer. That is, unless the world pays us a hefty ransom. - Dr. Evil, Austin Powers
Okay, the point is, both of these things have already happened. There is a Slashback category for this purpose. It just doesn't get used all the time.
A responsible and level-headed version of ORBS is very possible and quite welcome to me.
You're talking about RSS, right?
RSS has the same stated goal as ORBS - to allow people to block open relays if they so choose. But RSS is run by different people and is run much more responsibly. They do not probe IP blocks looking for open relays. They wait until someone submits a piece of spam with full headers. Then they check the relay listed in the spam to see if it is indeed open. If so, a human looks at it and blocks it. Once the open relay has corrected the problem, the RSS people take them off the list.
I believe ORBS also blocks anyone who does not allow their probing. RSS is blocked by ORBS, for example. I've also heard people say that it is very hard to get off the ORBS list. None of this is true of RSS.
I don't understand why people keep saying that the other browsers on Linux are still not "quite ready to take over for Netscape 4.77". Moz and Konq are both great, and have a somewhat different set of bugs. If a site is unusable on one I go to the other and it generally works great.
Because those freaks expect a single piece of software to accomplish a single task. They don't want to have to try one and switch when they encounter a bug, then back when they encounter another.
Realistically, I'm not satisfied with any of the browsers available for Linux. At the moment, I'm using Mozilla. This latest version is the first to seem fairly stable to me (meaning it crashes infrequently, not that it doesn't crash). But no matter what everyone says, it still is slow. When I click the back button in IE, I see the previous page at my previous location within the page. On Mozilla, I see it load the top of the previous page, pop in some of the images (seems like really small images don't cache or something, not quite sure) and reflow to fit them, then move to the previous location. All sorts of stuff that just makes it go slower and feel even slower.
Someone will reply about how the latest nightly build is better. It's inevitable; it always happens when talking about Mozilla. It's not fucking true. CVS versions of anything are not known for stability. Developers break things between releases. It's expected. If they didn't, the software wouldn't improve.
It bugs me when something is plugged for many different operating systems when I (admittedly not a coder, but I'm not totally clueless) can't compile it for the life of me on a recent stable FreeBSD release. This might not be such a problem if there was any kind of documentation, of any sort, anywhere, regarding other operating systems.
They aren't plugging it for many different operating systems. For each of their ports, they have a brief description of what is working and what isn't. In some cases, some pretty vital features are missing, and they aren't hiding that. VLC ports: BeOS, BSD, Linux, MacOS X, QNX RTOS, Solaris, and Windows. Click on any of those to get the current status of the port. In the case of BSD, it says encrypted DVD input is untested. So you've got a pretty limited selection of DVDs you can get to work, unless someone has managed to get that code working (it is possible they just haven't updated that page).
But the CSS crack is old news by now.
You're missing the point. This isn't "wow, the VideoLAN team managed to crack CSS with a cryptic ninety-line Perl script that you pipe from /dev/dvd into /tmp/obscenelylargefile." This is "wow, the VideoLAN team managed to create a portable, simple, well-documented CSS decryption library that lets you access the DVD as a block device without even caring if it's encrypted."
Yes, the fact that CSS can be cracked is old news. The fact that there's a very high-quality library to do so is not.
Remember that for standard use, Tux would only serve static content - this drastically reduces the possibilities for attacks against it.
But doesn't reduce the possibilities for attacks against your system, which is a better goal. You still need Apache around for CGI access. Now you potentially have very dangerous vulnerabilities in Tux running as worse-than-root in addition to your normal Apache vulnerabilities. I don't see that as reducing the possibilities of attack.
The article quoted Tux's creator as saying on linux-kernel that "there is nothing significant left in [Tux] that cannot be done from user space." I think this means that it's time for Tux to die off. It was a great tool for the kernel developers to increase speed in the kernel. Now it's done its job...hopefully soon someone will release a full-featured high-performance webserver that runs in userspace. (Not like Tux and X-15, one that actually handles dynamic content on its own.) Apache 2.0 might qualify, but I'm crossing my fingers.
Isnt this how some standard C functions work??
Not really. A lot of standard C functions do stuff like this:
They return an argument, but it is not dynamically allocated. Calling free() on it would be a bad idea. Advantage: callers don't need to worry about calling free(). Disadvantages: they need to duplicate it if they want it to be valid after the next call to the same function. You need to use a thread-specific data key to be safe in threads.
In fact, the only standard C function I can think of at the moment that returns something it malloc()s is strdup() (well, aside from malloc()/calloc()/realloc() themselves, of course).
On the whiteboard I would forgive simple syntax mistakes and the like. There don't need to be any function calls (a lot of people call strlen, which is fine, but not needed).
Remarkably few made one pass over the string to find the length, and then a single extra pass to do the reverse. Those are the people I was looking for :-)
I think the real problem is that you didn't know good code when you saw it. The best people were not the ones who looped over the string to find the length, but the ones who called strlen(). As the AC just said, strlen() is optimized, written in assembler. Plus, hat loop is just slightly harder to read than strlen(str) and a typo could cause a bug. This is much more true with more complicated functions. Use the existing stuff unless you've got a good reason not to. The standard C library functions are well-written and well-tested.
Otherwise, you've got what seem to me to be good ideas about interviewing. But you've made what seems a dangerous assumption to me - that there's one correct solution to the problem, and it's that one. I would say some of those people had better solutions, though I would still consider your way acceptable.
That wasn't updated. It's been in use since before 4.1-RELEASE. It was finally included (after years of testing) in OpenBSD 2.9. It's say it's pretty much a proven implementation at this point.
Thanks for the correction. I may be enabling it on my machine soon, then.
It's clear from their comments that they did not turn on Softupdates on the filesystems when they set up their FreeBSD machine for the testing.
Isn't soft update still in testing? My FreeBSD 4.2-RELEASE system says this in /usr/src/sys/ufs/ffs/README:
I don't see anything to support the idea that this changed in 4.3. In particular, I don't see any mention of soft updates at all in the 4.3 handbook. I'd expect to if it were a completed feature.
Obviously this "test" is a crock, as FreeBSD would not be that far behind, what with it's surperior network stack and thread handling.
This sounds very much to me like "I found this benchmark's results surprising, therefore I rejected them." You've given absolutely no evidence to support your claim that FreeBSD's network stack and thread handling are superior. You've said nothing about what mistakes may have caused their benchmarks to be skewed. If you are going to reject results you don't expect, what's the point of running the test?
I am not biased. I have all of these operating systems installed on my machines. The desktop I am at now is running Linux 2.4 and also has a copy of Windows 2000 installed. My colocated server is running FreeBSD. The old SPARCstation in the basement has Solaris (though, admittedly, I don't really use it).
It may be true that this is a very bad benchmark...but don't reject the results simply because they surprise you. Look into it...what was wrong with their test procedure? Without an answer to that, you have no credibility.
as opposed to the hashes unix keeps in /etc/passwd, which usually 33% can be obtained within hours, half within days?
I don't believe you. Prove it. Here's something I pulled at random from /etc/shadow. I don't know what this password is; obviously, I can check any answer you give me. It was chosen by someone who is not particularly security-conscious. I challenge you to break it: $1$s3m2axu1$QqizKegYZh5JLyXaCi/47.
Frank Poole is what I call a 90 percent anagram. The last 9 of the 10 letters of "[F]rank Poole" can be rearranged to form "[W]alk on Rope." I figured that one out by starting out with the knowledge that Frank Poole symbolized the rope dancer. Then I looked for phrases like "Rope Dancer," "Rope Walker," "Dance on Rope," and "Walk on Rope."
Here the author is committing a logical fallacy called the Texas Sharpshooter. A very short description of this fallacy: it is when you know the result before you begin the search for evidence. You then find evidence which matches your result, interpreting it favorably toward that result.
This fallacy got its name with a story. A man wants to prove he is a great sharpshooter, so he shoots at the unpainted side of the barn. He then draws a target around the bullethole. It is meaningless because the order is important. The target must be drawn before the bullet is fired, or the evidence must be gathered before the result is found.
Try something. Pick some element of mythology...any element of mythology. Think of short phrases that are related to it in some way. Then look 2001 (or any book/movie/play/whatever) for at least one of those phrases. You will find it. There are lots of anagrams of the character's names already without doing weird substitutions like cutting out the first letter of his name (why?!?) or changing "1" to "ONE". By the time you get to doing something like that, you are certain to find what you are looking for.
This proves nothing. You can say "[phrase]" is present, therefore [predecided conclusion]. That does not make it so.
(Disclaimer: I have not read the book. What I am saying here is based only on the review and the rebuttal.)
If you want to do something for the open source community right now, the last thing you would want to do is write another OS.
I hate to burst your bubble, but "do[ing] something for the open-source community" is not the primary goal of a lot of developers. They develop these projects because they learn something from them and they are fun. Helping out the open-source community is a bonus.
I quote the NewOS page:
NewOS exists to explore some aspects of modern OS design, and to have fun in the process. Also, I seemed to have collected a bunch of old non-x86 machines that need something running on them. I figure, "Hey, why dont I just port my OS over?" The rest is history.
If you really want to help the open-source community, stop posting to Slashdot and write good code. (And no, I'm not being a hypocrite here. I've never said it is my life's goal to contribute a great work to the open-source community. What code I write I do for the same reason this guy does. I/when I release any code, it won't be code I've written for the sole purpose of releasing.)
For the record, the definition is int getc(FILE *stream);
Not true. The definition is whatever Travis Geiselbrecht made it. You would have to look at the source code to know. This is not something that has to comply with ISO C, since it is in the kernel. In fact, it couldn't really comply to it...the userspace concept of a file descriptor in the FILE* structure doesn't really make sense, since each process's file descriptor table is distinct. The kernel deals with all of these, so a file descriptor alone doesn't uniquely identify anything. Without looking at the source code, I would guess the prototype he gave was char getc (void). It probably only deals with the console.
Look a little further up. The for loop with the getc() has no terminating clause and no break. So, with what we see here, this code would never be executed. The original poster is not quite correct, though, that this theoretically never will be executed. This is not the only thread running. Another thread could manipulate the instruction pointer and make that code execute. In my uneducated opinion (I know nothing of OS design), that would be dumb. I think the "Booyah!" bit is just code he no longer uses and didn't even bother to comment out.
I imagine sys_snooze(10^6) is a one-second sleep, not a million-second sleep. Without looking at the code for sys_snooze (I'm lazy), I'd guess it accepts microseconds, not seconds.
Keep in mind that in the kernel, none of the functions here are the ones defined by the libc...they are all for the kernel solely. The sys_snooze() is not the sleep() you know and love. The printf() and getc() are probably unbuffered. Someone else mentioned that this is sloppy code because getc() returns an int, not a char. You can't say that without looking at the getc() definition in the source, since it is not the POSIX getc.
Come on, you think the slashdot editors were too stupid to read this article before posting it?
Yes, I do. They have made progress toward real journalism. But this is incredibly sporadic. I think in this case Morgan read a tiny snippet of that FAQ, enough to see they would not boot from existing partitions. I think he did not read enough to realize that this was for a good reason, that the new standard is open, or that it only affects the 64-bit platform. I think Cliff read Morgan's submission only and didn't even look at the link.
Looking at the FAQ page linked to, I think this is a false alarm. Microsoft has several legitimate reasons for introducing this new partitioning scheme. It is an open standard; they link to the definition here.
It looks like a lot of the reason they are doing this is support for larger systems and disks. See these Q/As:
Q: If the disk is larger than the maximum size an MBR can report, will the entire disk contents be protected? A:The EE partition in the Protective MBR is specified to be the maximum size allowable in an MBR.
So the maximum size supported by the new format is greater than the old.
Q: Can the 32-bit version of Windows Whistler read, write, and boot from GPT disks?
A: No. The 32-bit version will see only the Protective MBR. The EE partition will not be mounted or otherwise exposed to application software.
This doesn't affect your current system at all. If you install Windows Whistler on your ia32 machine, it will use the old format.
Linux already has the support for many different partitioning schemes. I don't see this as different. There is no support for it now, but there will be when someone decides to develop it.
[Reposting with my login name. Didn't notice I wasn't logged in, and would prefer this comment actually gets read.]
So, protest with your dollars. Capitalism is a beautiful thing. You always have the option of taking your money somewhere else. If they can squeeze more cash out of you because you're unwilling to do your own due dilligence, then too bad. If they want to charge you $500 more than some other vendor because you told them (or they somehow figured out) that you make more than $75k a year, go somewhere else. If enough customers balk at the practice of dynamic pricing, IBM/Compaq/Dell will end up losing money, so it will make more financial sense not to do it.
Did you read the post you were replying to? Did you read the article? As BradleyUffner pointed out, the article says that these are based on market-wide supply and demand. His point was that IBM and Compaq's dynamic pricing is different from Amazon's in that what you are talking about doesn't happen. They don't change the price based on your income or anything else about you. Any two people loading the page at the same time get a different price.
[ Full disclosure: I work for a company that writes software to support "dynamic pricing" on web sites. ]
The site you work on may do the things you talk about, but unless the article is a complete lie, this site doesn't. Don't assume that IBM's pricing system is like yours.