Instead of throwing good money after bad, I ditched it and put Fedora Core 2 on.
Given the 9 month life cycle, how is that tenable? Nice as it is, I can barley afford the time to run it for personal use.
It's kind of sad, debian is too slow; RHEL is too expensive; and FCx can't be run for longer than a couple of months before you have to look for an upgrade. Hopefully someone will come along and produce something as a real RHL replacement. Maybe I'll have more faith in Mandrake soon.
FAIK, RFC1323 is not enabled by default in Windows 98, 98SE or XP.
Here's 2 cents kid, go buy yourself a real OS.
In the case of home firewalls, the people probably want to accept incoming connections but don't know it's not set up.
Right, so how is this different when the firewall vendors start distributing their personal firewall products with default off for the UDP case.
And at the end of the day, p2p will always be an arms race. This is par for the course.
Fine, as an arms race I can sort of see where the feature "implement TCP over UDP/HTTP/DNS/whatever" comes from. But you don't "design" your protocol with stupid TCP over UDP hacks in mind. You design for a reliable stream protocol, like say TCP.
POSIX threads; not only cross-platform and essentially built into C
You mean apart from win32, right?... that's only what, a couple of hundred million hosts.
Maybe python lets you do useful cross platform threading... but I didn't think so, and I'm not sure I'd classify it mainstream anyway (certainly not to the extent that Java is -- and personaly I think python is a better lanugage, but it isn't as mainstream).
Then again I think the entire argument is bogus, it's like advocating for GCC because that's the first compiler that allowed you to have computed goto's. Threads are not the answer, they are the question and the answer is no.
The implications are interesting: RedHat patches their hugely popular distro, sends their patches to Linus as required under GPL... The hypothetical patches have hypothetically changed the kernel API
Red Hat has never done this, API changing patches are only accepted into Red Hat kernels if they are already in an upstream kernel. Even things like the O(1) scheduler went into 2.5.x first before they were released into a product.
Sometimes the only patch that's gone "upstream" is the syscall reservations, but even that is only done as a last resort due to time constraints.
This isn't entirely selfless, they can't force Linus to accept them, and he hasn't shown any desire to fix distro's fuckups in the past... and they also get significant beta testing if everything is upstream.
Linux, in its current configuration and direction, will never be able to support the threaded processing capability Solaris currently is able to do with its hardware platform.
Which I guess is why Sun moved Solaris to the same threading model as Linux has with NPTL. And of course price performance, RHEL beats Solaris in Web server and Oracle benchmarks constantly (and at least for web server in absolute numbers). Then there's all the stories of Wall Street customers using RHEL for their in house apps. and getting something cheaper that goes faster. But hey, you have fun with your proprietary POS. Just don't complain on/. when you can't get a job anymore.
Threads as a way of life, rather than as an afterthought.
Yeh, this seems to be the big feature (the others can as easily be implemented in Linux -- and already have). However it presupposes that having everything use lots of threads is a good idea. This is not how scalable daemons are written now, and it's certainly not how reliable ones are. But hey, they're having fun.
I will take a media who talk to both sides over someone who presumes to know the truth about global warming. Period.
So, in my world view, the "news" might have printed that the world was flat until, at the latest, the 1st century AD. Fine, my bad. However, in your world view, you still print that it might be.
The only "scientists" that argue that global warming isn't occuring, or that Big Oil etc. aren't involved if it is occuring are repeatedly debunked as liars or just extremely bad scientists (and even then still repeat their claims). The scientists arguing that global warming is occuring, not so much. Have fun in your flat earth society.
But here's the thing, if I was saying this to a blacksmith in 500AD (a point where blacksmithing had been around for so long as to seem forever) and asked him to create a 747 he would still be whinning about bad tools for well over another millenium. This is the difference between AI bullshit and the rest of the world... yes, you might be able to do it in another 1000 years, but so what it might as well be physically impossible as far as planning for it now.
Tbjw said "X+2 and X+3 are both non prime, where X is a factorial greater than 3" this being because the factorial has to start with 2x and 3x (if X is divisible by Y, then X+Y is also divisible by Y).
In the second, MS wasn't using the FAT patent against software developers, ie.. their competitors. They were using it against camera manufacturers and other other embedded devices.
Right, if you work for a camera manufacturer you're suddenly not a software developer anymore. I can't think why those Linux shills didn't realize this it's all so obvious.
Even then, it was entirely voluntary, as MS never sued anyone over it.
Of course, lots of negative PR and they'd probably lose. It's much better to just imply that you're going to sue everyone, much like SCO has been doing.
Compared to most of the UK tabloids, the US press is a model of probity.
Right, if you take a small portion of the English press and compare it to a small portion of the US press that is "better"... then the US press it better.
In reality, there are a lot more newspapers in the US (shocking given the relative sizes, I know)... and there are national "newspapers" that are worse than "The Sun", in England. I'd also say that, in general, the newspapers in the US are more conservative... and generally just less confrontational with the government (Ie. just reprint whatever lies they are saying this week).
First off, it handles multi-threading much better meaning that very heavy workloads require less CPU time[*]
Well that's hard given that apache-1.3.x doesn't use threading at all. Of course all the Linux distributions still ship with the "old" pre-fork method, because it's just as fast on Liunux... and much safer, reliable and compatible.
[*] Why is multi-threading faster... Changing virtual address spaces is slow because it requires a TLB flush
Doing a task switch, even without a TBL flush, is still much slower than not doing a task switch at all. Using two servers, apache for dynamic content and a fast one for static content is fairly common... and much faster than apache 2.0.x.
And you are sacraficing a huge amount of reliability for that small TLB "improvement", then of course you have to take into account the extra locking needed in the threaded app. and the SMP cache invalidation traffic when you alter hot objects etc. Of course I'm sure you've measured all this... not.
I assume it's for things like realtime video/music streaming. You can blast it out from the server, and once it's gone you never need to go back. Where in TCP you have to keep hold of it for some extended period so you send it again if you don't get ACKs. From the server's POV this would be a big advantage.
Seriously though, wouldn't it be better to drop the 500 line gimmick and just solicit the best work? It's not as if code size is going to tip the balance from closed to open source.
I assume it's a practical matter. I can look at an entire program in 500 lines of code and come to a conclusion within a short amount of time. If given 15,000 lines on the other hand I'd simply have to miss bits.
Nearly ever existing widely used protocol has NO framing protocol associated..
This is not true. SMTP, HTTP, NNTP, and DNS all have an obvious "frame" that you can parse out without knowing what is inside it. SMTP, NNTP and HTTP headers all have a terminator. HTTP content and DNS have length's that are sent before content. AIUI XMPP just has, parse this XML document, and it ends when it ends.
Let me explain further. The amount of content provided over an HTTP connection doesn't always correlate directly with the size reported in the HTTP headers. Not only THAT, but it doesn't reflect the fact that sure, my document is, say, 10k
You are confused. The protcol talks about Entities, and the framing encompasses those entities. Those entities can be displayed on their own, however you might want multiple entities to display a full document. But each entity can be downloaded via. a completely seperate process (Ie. "wget -r examples.com/foo.html; browser foo.html").
There are benifits of parsing data without stanza. It means you can process it real time instead of waiting for the entire message to DO something.
This is not true, XML does not have content ordering, so you can parse your input... but the part of the XML you need first might well at the end of the XML document sent to you.
Protocols like XMPP can also benefit in terms of memory for any case where the server is acting mainly like a router, as a decision can be made while messages are still incoming to stop storing the message contents and just start pushing the message down the recipient connection. It's a cheap and reasonably simple optimization to make, that if implemented "right" will at the same time throttle the sender to whatever speed the recipient is ready to accept data at, reducing the rate the server needs to process the message with.
Which can't be done with XMPP, because there's no terminator and no length. So, even after you've decided that message X just needs to be resent to connection Y through Z you still need to parse the rest of the message a byte at a time through the XML parser.
In contrast to web caches, where you can either search for \r\n\r\n or the end of the content length.
This statistic is a little crude because it doesn't take into account very very different levels of gun ownership from place to place. For instance, guns are entirely banned in Washington DC, and DC is often the most likely place to be murdered by a gun in the US.
But given that most of the US has very little gun laws compared to the UK it should show up overall (all other things being equal). It's also true that even if DC doesn't allow any guns at all, it's much easier to get a gun into DC than into the UK (no border, for example).
A much bigger problem is that it doesn't take into account the differences in how crime is categorized in the UK and US. For instance if you just have a gun on you in the UK it's going to be a big deal no matter what you've done (and probably counted as "gun crime"), where in the US it's not.
So you are left to looking at the studies in the US, and in summary they don't support your position.
The point we Americans are making is;
Of all those scary guns you have seen, how many of them actually shot you?
Now here's the other question; Of all those surveillance cameras, How many of those have actually shot you?
So you are standing in front of an object, and if it's a camera you have 100% chance it'll "shoot" you but if it's a gun you have 0.001% chance it'll shoot you... which would you rather it be?
Saying that, the stats. I've seen for CCTV is that it doesn't deter major crimes anyway (although that's often the reason they are bought) only minor ones.
Just as an example off the top of my head, it's common to write
if (condition = immediate)...
Yeh, I've seen a lot of people think that one up off the top of their head when in these kinds of discussions. So here's my std. answer: "Here's two cents kid, go get yourself a copy of GCC".
I can't even remember how many years GCC has warned on the above, but even if you come up with a valid problem that is repeatable and can't easily be found vbia. the compiler. Yeh, let's use code reviews (large resources drain on multiple people, only useful once) instead of unit tests (single resources drain, can be run nightly until the heat death of the universe).
I'm not saying code reviews should never be used, but if your code reviews keep turning up the same problems... it's time to start firing people.
And there will be nothing tying MS to the x86 architecture.
Except for Microsoft themselves. They've already dumped PowerPC, MIPS and Alpha support to release solely on x86.
While I've never worked for Microsoft, I assume the problem went something like this... 1) MS release OS for non x86 arch. 2) Not many users, so no software is released. 3) No software so no users. 4) MS pulls arch because it cost X million, and they haven't sold any copies.
In theory, having a virtual machine helps because all your apps. now work just as badly on all platforms. Although, personally, I'm not convinced that you can get all ISVs to say they support all platforms, at which point you are probably just as screwed.
And I know now that YOU misunderstood what the grand parent was saying. Because all the grand parent is saying is based on flawed stereotypes.
Apps can be made to support every innovation, as long as it is FOSS !
Think of it this way, reiserfs can AFAIK support transactions, but almost no applications support that. Because as soon as you did it wouldn't work on ext3, XFS, JFS or FreeBSD. Who is going to intentionaly cripple their app. portability like that, and with something that is arguably better implemented elsewhere? The same is true for kqueue() on FreeBSD, only a very small number of *BSD only apps. use it... for everyone else running on Linux is much more important, so you can't use it[1].
This is the difference, and it's not an advantage IMO, in Windows Bill can say "the FS will have transactions, an XML schema, or whatever and all applications will use that" and then as if by magic all technical reasoning will (nay must) be ignored. Sometimes this might be a good thing, but I prefer it the way it is in Linux.
[1] By not using kqueue() I mean not using the advanced features of combining all the different types of events, into one call. Using it as an fd notification system that is just faster than poll() is portable and does have similar things like epoll() etc. on other systems.
More women are enrolled in law schools, journalism schools, and soon, they will exceed men in all professional schools, with the exception the dreary schools of engineering and business.
There are always more students than qualified practitioners. The usual way this stat. is abused is to say "there are more law students in the US, than lawyers... so soon we'll be overrune with them".
In pretty much every high earning business I see men outnumber women, esp. as the pay scale goes higher (very few CxOs, very few politicians, no presidents etc.) And maybe some professions will naturally tend towards one or the other gender over time, but I really can't see lawyers being female dominated given how good men are at being lying bastards (it's ok, it tastes like a strawberry lollipop... no really it does:).
Any
decent corporate network will be VLAN-ed well enough that a break-out will not affect the whole network
hahahahaha.
Every large corp. network I've seen has had at least one machine on the intranet that is accessible from everywhere and has a security policy of "There's no rush, it's all behind the firewall".
That may be true, but every system I use takes the sensible route of not making people's scripts break if the user's locale has different collation, except RedHat.
Although I was 99% certain when I read your web page I did check. All the output I posted was from my debian stable machine. It works as it should on debian stable (presumably when when configured properly, as you seem to not have done so). It does exactly the same as Red Hat and it must have done so for over two years. And this shouldn't be a shock to anyone, debian and Red Hat get their grep and glibc from the same upstream source... and I doubt either would permenantly diverge on something like POSIX compliance for locale information.
If you don't understand why, let me provide you with a few reasons:
a) More code on the system means more code to keep patched, more security holes.
b) You see the iptables script is in the current run level, so you go edit the iptables config. Whoops, except ipchains runs first. That's the sort of thing that can waste hours of a person's time.
c) ipchains is obsolete. If you're doing a clean install (which I was), why the hell install obsolete software which will never be used at best, and at worst might actually cause me to waste my time or even suffer a security problem?
a) AFAIK it's the same backend, just the interface is different... but yeh go with generic defense #1. b) AFAIK ipchains doesn't stay loaded unless you have a configuration, so if you just configure iptables all should work. c) It's obsolete because you say so? Or do you just mean old, but then so is vi and that still gets installed... maybe because humans can't download software updates, so why not allow people to continue using ipchains if that's what they know?
The first two points are labeled AFAIK because I can't be bothered verifying it, for you.
Slashdot Mirror
Given the 9 month life cycle, how is that tenable? Nice as it is, I can barley afford the time to run it for personal use.
It's kind of sad, debian is too slow; RHEL is too expensive; and FCx can't be run for longer than a couple of months before you have to look for an upgrade. Hopefully someone will come along and produce something as a real RHL replacement. Maybe I'll have more faith in Mandrake soon.
Here's 2 cents kid, go buy yourself a real OS.
Right, so how is this different when the firewall vendors start distributing their personal firewall products with default off for the UDP case.
Fine, as an arms race I can sort of see where the feature "implement TCP over UDP/HTTP/DNS/whatever" comes from. But you don't "design" your protocol with stupid TCP over UDP hacks in mind. You design for a reliable stream protocol, like say TCP.
You mean apart from win32, right? ... that's only what, a couple of hundred million hosts.
Maybe python lets you do useful cross platform threading ... but I didn't think so, and I'm not sure I'd classify it mainstream anyway (certainly not to the extent that Java is -- and personaly I think python is a better lanugage, but it isn't as mainstream).
Then again I think the entire argument is bogus, it's like advocating for GCC because that's the first compiler that allowed you to have computed goto's. Threads are not the answer, they are the question and the answer is no.
Red Hat has never done this, API changing patches are only accepted into Red Hat kernels if they are already in an upstream kernel. Even things like the O(1) scheduler went into 2.5.x first before they were released into a product.
Sometimes the only patch that's gone "upstream" is the syscall reservations, but even that is only done as a last resort due to time constraints.
This isn't entirely selfless, they can't force Linus to accept them, and he hasn't shown any desire to fix distro's fuckups in the past ... and they also get significant beta testing if everything is upstream.
Which I guess is why Sun moved Solaris to the same threading model as Linux has with NPTL. And of course price performance, RHEL beats Solaris in Web server and Oracle benchmarks constantly (and at least for web server in absolute numbers). Then there's all the stories of Wall Street customers using RHEL for their in house apps. and getting something cheaper that goes faster. But hey, you have fun with your proprietary POS. Just don't complain on /. when you can't get a job anymore.
Yeh, this seems to be the big feature (the others can as easily be implemented in Linux -- and already have). However it presupposes that having everything use lots of threads is a good idea. This is not how scalable daemons are written now, and it's certainly not how reliable ones are. But hey, they're having fun.
So, in my world view, the "news" might have printed that the world was flat until, at the latest, the 1st century AD. Fine, my bad. However, in your world view, you still print that it might be.
The only "scientists" that argue that global warming isn't occuring, or that Big Oil etc. aren't involved if it is occuring are repeatedly debunked as liars or just extremely bad scientists (and even then still repeat their claims). The scientists arguing that global warming is occuring, not so much. Have fun in your flat earth society.
But here's the thing, if I was saying this to a blacksmith in 500AD (a point where blacksmithing had been around for so long as to seem forever) and asked him to create a 747 he would still be whinning about bad tools for well over another millenium. This is the difference between AI bullshit and the rest of the world ... yes, you might be able to do it in another 1000 years, but so what it might as well be physically impossible as far as planning for it now.
Tbjw said "X+2 and X+3 are both non prime, where X is a factorial greater than 3" this being because the factorial has to start with 2x and 3x (if X is divisible by Y, then X+Y is also divisible by Y).
Right, if you work for a camera manufacturer you're suddenly not a software developer anymore. I can't think why those Linux shills didn't realize this it's all so obvious.
Of course, lots of negative PR and they'd probably lose. It's much better to just imply that you're going to sue everyone, much like SCO has been doing.
Right, if you take a small portion of the English press and compare it to a small portion of the US press that is "better" ... then the US press it better.
In reality, there are a lot more newspapers in the US (shocking given the relative sizes, I know) ... and there are national "newspapers" that are worse than "The Sun", in England. I'd also say that, in general, the newspapers in the US are more conservative ... and generally just less confrontational with the government (Ie. just reprint whatever lies they are saying this week).
Well that's hard given that apache-1.3.x doesn't use threading at all. Of course all the Linux distributions still ship with the "old" pre-fork method, because it's just as fast on Liunux ... and much safer, reliable and compatible.
Doing a task switch, even without a TBL flush, is still much slower than not doing a task switch at all. Using two servers, apache for dynamic content and a fast one for static content is fairly common ... and much faster than apache 2.0.x.
And you are sacraficing a huge amount of reliability for that small TLB "improvement", then of course you have to take into account the extra locking needed in the threaded app. and the SMP cache invalidation traffic when you alter hot objects etc. Of course I'm sure you've measured all this ... not.
I assume it's for things like realtime video/music streaming. You can blast it out from the server, and once it's gone you never need to go back. Where in TCP you have to keep hold of it for some extended period so you send it again if you don't get ACKs. From the server's POV this would be a big advantage.
I assume it's a practical matter. I can look at an entire program in 500 lines of code and come to a conclusion within a short amount of time. If given 15,000 lines on the other hand I'd simply have to miss bits.
This is not true. SMTP, HTTP, NNTP, and DNS all have an obvious "frame" that you can parse out without knowing what is inside it. SMTP, NNTP and HTTP headers all have a terminator. HTTP content and DNS have length's that are sent before content. AIUI XMPP just has, parse this XML document, and it ends when it ends.
You are confused. The protcol talks about Entities, and the framing encompasses those entities. Those entities can be displayed on their own, however you might want multiple entities to display a full document. But each entity can be downloaded via. a completely seperate process (Ie. "wget -r examples.com/foo.html; browser foo.html").
This is not true, XML does not have content ordering, so you can parse your input ... but the part of the XML you need first might well at the end of the XML document sent to you.
But given that most of the US has very little gun laws compared to the UK it should show up overall (all other things being equal). It's also true that even if DC doesn't allow any guns at all, it's much easier to get a gun into DC than into the UK (no border, for example).
A much bigger problem is that it doesn't take into account the differences in how crime is categorized in the UK and US. For instance if you just have a gun on you in the UK it's going to be a big deal no matter what you've done (and probably counted as "gun crime"), where in the US it's not.
So you are left to looking at the studies in the US, and in summary they don't support your position.
So you are standing in front of an object, and if it's a camera you have 100% chance it'll "shoot" you but if it's a gun you have 0.001% chance it'll shoot you ... which would you rather it be?
Saying that, the stats. I've seen for CCTV is that it doesn't deter major crimes anyway (although that's often the reason they are bought) only minor ones.
You probably also want to read this guy.
Yeh, I've seen a lot of people think that one up off the top of their head when in these kinds of discussions. So here's my std. answer: "Here's two cents kid, go get yourself a copy of GCC".
I can't even remember how many years GCC has warned on the above, but even if you come up with a valid problem that is repeatable and can't easily be found vbia. the compiler. Yeh, let's use code reviews (large resources drain on multiple people, only useful once) instead of unit tests (single resources drain, can be run nightly until the heat death of the universe).
I'm not saying code reviews should never be used, but if your code reviews keep turning up the same problems ... it's time to start firing people.
While I've never worked for Microsoft, I assume the problem went something like this... 1) MS release OS for non x86 arch. 2) Not many users, so no software is released. 3) No software so no users. 4) MS pulls arch because it cost X million, and they haven't sold any copies.
In theory, having a virtual machine helps because all your apps. now work just as badly on all platforms. Although, personally, I'm not convinced that you can get all ISVs to say they support all platforms, at which point you are probably just as screwed.
Think of it this way, reiserfs can AFAIK support transactions, but almost no applications support that. Because as soon as you did it wouldn't work on ext3, XFS, JFS or FreeBSD. Who is going to intentionaly cripple their app. portability like that, and with something that is arguably better implemented elsewhere? The same is true for kqueue() on FreeBSD, only a very small number of *BSD only apps. use it ... for everyone else running on Linux is much more important, so you can't use it[1].
This is the difference, and it's not an advantage IMO, in Windows Bill can say "the FS will have transactions, an XML schema, or whatever and all applications will use that" and then as if by magic all technical reasoning will (nay must) be ignored. Sometimes this might be a good thing, but I prefer it the way it is in Linux.
[1] By not using kqueue() I mean not using the advanced features of combining all the different types of events, into one call. Using it as an fd notification system that is just faster than poll() is portable and does have similar things like epoll() etc. on other systems.
There are always more students than qualified practitioners. The usual way this stat. is abused is to say "there are more law students in the US, than lawyers ... so soon we'll be overrune with them".
In pretty much every high earning business I see men outnumber women, esp. as the pay scale goes higher (very few CxOs, very few politicians, no presidents etc.) And maybe some professions will naturally tend towards one or the other gender over time, but I really can't see lawyers being female dominated given how good men are at being lying bastards (it's ok, it tastes like a strawberry lollipop ... no really it does :).
hahahahaha.
Every large corp. network I've seen has had at least one machine on the intranet that is accessible from everywhere and has a security policy of "There's no rush, it's all behind the firewall".
Although I was 99% certain when I read your web page I did check. All the output I posted was from my debian stable machine. It works as it should on debian stable (presumably when when configured properly, as you seem to not have done so). It does exactly the same as Red Hat and it must have done so for over two years. And this shouldn't be a shock to anyone, debian and Red Hat get their grep and glibc from the same upstream source ... and I doubt either would permenantly diverge on something like POSIX compliance for locale information.
a) AFAIK it's the same backend, just the interface is different ... but yeh go with generic defense #1. b) AFAIK ipchains doesn't stay loaded unless you have a configuration, so if you just configure iptables all should work. c) It's obsolete because you say so? Or do you just mean old, but then so is vi and that still gets installed ... maybe because humans can't download software updates, so why not allow people to continue using ipchains if that's what they know?
The first two points are labeled AFAIK because I can't be bothered verifying it, for you.