And python and perl aren't? At least I can write a secure "rm -rf" in the later two... in Java security is sacrificed for "portability". And it even fails at that due to every deployment of Java I've seen having the most fucked up env setup scripts I've ever seen, which make it a major PITA to move from one machine to another.
No, I'm not. As I said, I can only assume that you have screwed up your locale settings on the machines you had to do it manually on (Ie. the non Red Hat boxes). See bash NOTES point 13, where it repeats what I've told you. Even searching for "en_US locale" on the debian lists gives: this message, among others, which confirms what I told you. Although the most recent message seems to be advocating breaking collating in the locale because of people like you.
All you have proven is that you can't listen, and can't configure you locale settings (or, I guess it's possible, that you've just broken your machines in some more fundamental way... whatever).
9. Yes, that's what I mean by clash. Two packages are installed, only one of which can actually be running. Which is stupid.
Why? I can only run one editor at once, so should I not be able to install two? I can only run one web server on the default port at once, so should thttpd refuse to install if apache-httpd is there?
2. Debian testing uses GCC 3. You don't have to go to unstable.
Debian testing also don't guarantee security updates, and more than one remotely accessible app. has gone months without known security updates. The debian response is that this is expected, and people using testing shouldn't be using it in production (that's what stable is for) and should be closely following development so they can install from unstable/stable if they need to.
5. No, Fedora Core isn't ready for the desktop. But Linux is.
Right, because debian is so much more usable. I didn't say FC1, I said Linux circa. FC1... Ie. Linux that was available at the time the comment was made. And it wasn't said that Linux wasn't ready for the desktop, just that it wasn't ready for the average consumer (Ie. mom's who have their quilt design package, Pop's who have MS train simulator, little joey who plays games). Red Hat have more than a few customers using it on the desktop already, this is not the same thing.
6. Oh yeah?
$ echo $LC_CTYPE
en_US
$ echo $LC_COLLATE
en_US
$ echo does it really | grep [A-Z]
$
Run "locale", certain env. variables override others. I can't say I'm shocked that you've set it up incorrectly. Or don't bother, just run...
% echo does it really | LANG=en_US grep '[A-Z]' does it really % echo does it really | LANG=C grep '[A-Z]' %
...then you don't have to bother replying.
8. And what about the ones that aren't up to date?
I rarely care about having the very latest perl modules, and if I do... I can just update the srpm from red hat and upgrade, this is even easier than creating new packages. Or maybe you mean what about updates? That needs to be handled either way... unless you're insane enough to have some auto update CPAN code?
9. They're both placed in the init sequence for the default runlevel. That's what I mean by both active. Obviously they clash when they both try to run, duh.
Yes they can both run, but they don't clash... for instance my iptables init.d file contains...
if lsmod 2>/dev/null | grep -q ipchains ; then echo -n $"ipchains and $IPTABLES can not be used together."; warning; echo exit 0 fi
And if you reply, without checking your facts in a reasonable way, I doubt I'll bother replying... it should be obvious to anyone reading this thread that you appear to be clueless.
2. Oh yeah, wheel out the "Debian takes years to update" lie. The point isn't whether jar works by default, it's that a libraries package has no business installing new commands at all, let alone broken ones.
It does, gcc=2.95.x, bind=8.x.x, (Ie. historic). Unless you want to use "unstable"... which is errr. unstable. And if you do... fine, what do I care, you can use slackware if you want... but that sure as hell isn't more usable than Fedora by any measure.
3. You prefer resolving dependencies manually? Oh well, no wonder you enjoy RedHat.
I think you are confused. I haven't done that for years, with Red Hat and Fedora. Just as I'm sure you don't use dpkg manually with debian.
5. "I would say that for the consumer market place, Windows probably continues to be the right product line,"
So you are suggesting that Linux circa. Fedora Core 1 could win a viable majority of the consumer market? Or maybe that knowingly lying about it to people is a good idea (actually given your responces, if the shoe fits...).
6. You didn't try it. echo redhat sucks | grep [A-Z] prints "redhat sucks" on RH9, even though the string contains no capital letters. That's simply broken in en_US.
I can see you are confused, so I'll put this in bold: That is correct behaviour for en_US. Here's a free clue, in en_US the layour of the characters is "AaBbCc...Zz" you did the character group [A-Z] and so got the entire alphabet excluding "z".
Here's another free clue, if you set your locale as en_US on debian stable... it does the same thing. Of course debian doesn't set the locale for you on install/upgrade, just as it doesn't do many other things... but that's fine if you know what you are doing.
7. The "emacs with no X" requires X. You can't see that there's a problem with that?
Sure, I can see that it'd probably be better to not depend on "the X libraries". But, to be frank, it's almost impossible to do that on debian too. Hell, debian's exim package depends on a whole bunch of crap I don't want... but I think I can sacrifice the 1 of disk space in both cases and just not care.
8. I explained why you can't rely on RPM for CPAN stuff. I thought you didn't like waiting years for updates? How come you're willing to use years-old versions of Perl libraries?
No, you said that not all CPAN modules are in rpm packages from Red Hat... Oh my god, news at eleven. Your "solution" to this is to completey remove rpm from the picture... my solution is to spend the 2 minutes to make rpms for the missing CPAN modules I need.
9. It's not rebooting that's the issue, it's wiping and reinstalling.
Why would you do that... as I said, it works. Put CD in drive, reboot, choose upgrade.
10. Again, if you don't see the issue with having both iptables and ipchains installed and active at the same time by default, you clearly don't know what they do.
I think you are confused (I'm seeing a pattern here), iptables and ipchains are both installed... but it's not possible to have them both "active", if you have ipchains rules then they will continue to work. If not, you can create iptables rules... you can't have both.
Hahahaha. But whatever, I'm up for taking 5 minutes to do some simple troll killing.
1. Rpm isn't perfect, but it's far better than you imply. It almost never crashes, and fixing an rpm DB is very painless.
2. *shrug*, debian is at least as bad (I had to install xemacs from tarballs throught "potato" because the package was so broken). Plus you get joyful things like the modem defaulting to 1970s speed on debian.
And with Red Hat I won't have to wait 5 years for an update... plus this is Java, on the Free beer product. So what, I don't care and I'm pretty sure jar will just work in RHEL 3.
3. Yes, I have. And I much prefer rpm/yum over dpkg/apt.
4. Err, yeh. Whatever. Pass the crack pipe etc.
5. Please learn to read, "I would argue that... for that classic consumer purchaser, it is my view that (Linux) technology needs to mature a little bit more." is not close to what you implied.
6. I assume you are running in an en_US locale so grep is doing what you told it to. How terrible for you.
7. By "X" I presume you mean some of the libraries, my how terrible this bug must be for you at todays prices this has to be at least 1 of disk space.
8. You can break your machines however you wish, I fail to see how that's Red Hat's fault though. All my perl stuff is in RPM format, and life is good.
9. This is complete crack, it's at least as easy as upgrading debian... the big difference being you need to reboot on Red Hat, which is a nice propert of debian... but hardly worth the 5 year waiting period.
10. Oh woe is you, another 1 of disk space on backwards compatability.
Then you have to realise that you don't get guaranteed security updates with testing, and indeed some well known remotely available packages have gone months before the security errata rolls into testing.
Debian stable isn't bad, if you don't mind being 3-5 years behind the curve, and indeed in some cases I don't but it's sure as hell not my first choice.
But, hey, you do what you want. If you don't screw it up too bad, well done... and when^Wif you don't, I can come in and offer your company a solution.
Of course not. RedHat does not actually write any software (well, not anything important anyway:)
Riiight, feel free to pass the crack pipe around so everyone can get a bit. Unless you don't consider the linux kernel, glibc, binutils, GCC, elfutils, libxml, glib, gtk, metacity or dict "important"... and that's just off the top of my head where at least a significant portion (in a few cases, basically all) of the developers are directly employed by them. And if you include useful stuff which isn't included in every major distro. or include stuff they wrote but don't maintain now the number goes up a _lot_.
You could probably argue that in some cases the employees wrote those things "outside" the company, by either spending time on it before they were employed or time when they might otherwise call non-work time. But I'd retort that basically the same thing happens in other companies, it's just more transparent with Red Hat.
If you hit the hash with only breaking some never-used apps and obscure device drivers then distribute compromised CD. So I'd say 2 and 3 were the same thing.
That's more like three than two, two is where you generate a large random file that hashes the same as the iso (thus making downloads look ok, but actually be bad). If you can start with some known data, and then append something to make the hash be what you want then, yes, that's almost as bad as starting with the original and altering it but keeping the hash.
You also have other problems like the.iso you end up with really needs to be the same size and you probably need to break both MD5 and SHA-1 on the same file, which is probably much harder.
On the other hand, a re-compiler can watch what is happening, and generate better code.
As an example:
if (condition) {...simple code...
}... more code...
When compiled, I cannot tell C (or C++) that "condition" is an error that will occur.. well, should never occur..
among the OSS components that would be shut off is the BSD TCP stack, which happens to be not just in Linux, but Windows, and most likely 99% of all computer systems on the continent.
Every MS tech that I've ever heard speak about it has said that MS did their own stack from the ground up. I know Linux did their own stack from the ground up. Why repeat such obvious lies?
That's funny given that apache uses one task per connection, and kqueue/epoll/etc. only help when you have many fds to get events for and most of them are "idle". In fact I'm pretty sure Apache uses blocking read/write calls.
The main reason Java got popular was [...] and a giant class library that had pre-canned solutions for most things.
Oh, my god stop the press. Not having to re-invent the wheel is seen as a benifit. Why is it that all these so called "great lisp hackers" can't understand this one simple fact. The reason I learnt perl was that I could just do...
my %foo =/^(.+):\s+(.+)$/g;
...and have it work (without having to write a Regexp library), in a similar vein I wouldn't have learnt python if I couldn't do multiple https GET/POST calls in a couple of lines of code keeping cookies over the session.
I've never written in Java, and have no intention of doing... but I can see that having a massive std. library is a major benifit over lisp/scheme etc.
I don't think it was a particularly childish comment, the LSB has done nothing but document how the Redhat and SuSE (now Novell) distributions do things.
I don't think that's true. Possibly more weight was given to RH/SuSe... but then they have more users. There are Debian users/maintainers on the LSB.
Yes, third party packaging was defined as a very old version of RPM... but then you have to take into account it is debian with deb's on one side and RH, SuSe, mandrake, caldera, turbo Linux, etc. etc. on the other side with rpms. And most of the differences at that level are aimed at proprietary third parties, everyone in the Open Source world just makes two versions a deb for debian and an RPM for everyone else.
Everything else, like ABIs etc. are mainly lowest common denominator and hence tend to favour Debian, if anything.
The libc5 to libc6 transition was done to improve the technical position, and it was not backwards compatible either, some software had to be recompiled just to co-exist, packaging methods had to be rethought. Similarly for gcc 3.2 and C++.
When the libc5 -> glibc move happened I was still compiling my own kernel and libc. I think I had a copy of the Applix suite... but I can't remember. And even then, it wasn't too bad you could have old and new apps. running in the same places... you just had problems with shared libraries (but even then, there was much less shared library usage... everyone used libc, X stuff used libX* and libc and some other stuff used a couple of others, like zlib) -- you could do new version of 99% the shared libraries by compiling less than 10 tarballs.
That's very different to today. C++ didn't even come close, mainly because not as much stuff used it... and also because vendors did recompiles as groups (and the older versions in the same place as before continued working).
Trashing ABI compat., at this point, would be orders of magnitude more painful. Every app/lib would need to move, with copious hacking/wrappers to the binaries and even then it would fail randomly for years IMO.
AMD can want sugarlumps supplied in boxed Debian sets, but AMD design Microprocessors - they have never even attempted to demonstrate their O/S design abilities.
However they have demonstrated backwards compatability, a great deal more than the Linux community has had to do. And they paid everyone, thus invoking the golden rule. Certainly large companies buying AMD64 boxes will be buying them so they can run their x86 Oracle etc. better than before.
Debian is not very compatible with other Distros anyway, the packages have to be transformed via alien, and I see no reason why Debian can't translate file operations to/lib depending on arch anyway.
That's fine, they can do whatever they want... they can just say fuck everyone else we'll do it our way. And everyone else will ignore them.
(and here's the great thing about Debian) they don't have to make money, so they don't have to release crap software just to release in time to get your money.
Define "crap software" certainly compiling anything on Debian that just used libc and the kernel can be a crap experience... I've found/reported compiler bugs over 18 months ago, that were just responded with "sorry, no man power... don't do that".
No Open Source product "has to release" to make money. Most of the good ones realize that releasing more than once every three years is a good thing though. And more than a few think that having newer, faster tech. like a decent compiler, threading, LVM, GUIs etc. isn't such a terrible thing either.
LSB (Linux Standard Base) is a misnomer, it should be RNSB (Redhat and Novell Standard Base).
Grow up.
the AMD64 Pure64 port does not run 32bit binaries (except in a chroot)
...which is why it's incompatible to everyone else. Look sparc64 had (has?) a 32 userspace for a long time. 32 bit apps. can run faster (I think they often do, actually), with a 64bit kernel... and they are a hell of a lot smaller, on disk and in memory. And AMD explicitly wanted the layout so you could just use the AMD64 as a faster x86 for a while, if you wanted to... then upgrade at some later point (but still run your 32bit oracle etc.... just as you did before).
The multiarch solution is the technically superior one
Possibly, but it's not backwards compatible... and it's not compliant with the LSB. For instance it's not hard to create an new x86 ABI that's faster (technically superior) than the current one, but the fact that it's not compatible with the one everyone else is using would be a pretty big reason to ignore it, if someone did one.
In another way I, personally, probably would prefer all the 64 bit stuff in/lib/usr/lib etc. and have some/usr/i386-chroot directory tree that I run all my old 32 bit apps under... but, again, the fact that it's not what everyone else would have is a big reason for me not to do that.
As I understand it, what you said is not true. The LSB requires that amd64 have the 64 bit libs in/lib64 and the 32 bit ones in/lib... mainly because that's what AMD wanted (the intention being poeple could/would buy/use AMD64 as a fast 32bit CPU and then at some point "upgrade" to 64bit).
Debian has refused to do this, thus the amd64 "port" of debian isn't LSB compliant.
So what are you complaining about... the fix seems obvious to me. Just bandwidth limit all RSS requests connects between x:00:00 and x:01:00 to 1KB/s or something. Or just block those IPs for an hour. This isn't html, if I happen to open my RSS reader during that window one day... so what. I'll get it the next, or later that day if I open it again.
All the retarded RSS readers get what they deserve, sucks to be them or their users... the coders will work out how to stop being so retarded, or their users will work out how to find an RSS reader written by someone who has.
I'd also bet that you'd only need to have this policy for a while, and then the problem will stop (or so be much smaller you don't care anyway).
Yes but the number is stored as ascii, so there is no reason to belive it is limited to 32bit integers.
No, it's not, from rfc1035.txt...
3.3.13. SOA RDATA format
...
SERIAL The unsigned 32 bit version number of the original copy
of the zone. Zone transfers preserve this value. This
value wraps and should be compared using sequence space
arithmetic.
The quality of a web site is determined more by it's substance than by it's appearance.
This is a cute soundbite, but real life isn't that clear. For instance project gutenberg has lots of substance, the appearance is so horrible that the quality is severly reduced.
It always seemed strange to me that the Linux C library (glibc)
But that isn't The Linux libc, it's one of a few choices... although admitedly the most popular. Other choices include uClibc, klibc and even dietlibc.
And the libc/kernel actually have a pretty well defined boundry, so it doesn't seem strange at all to me. Actually I see the "discussions" between the kernel and glibc maintainers and can't help but thinking that a better solution to a problem is found because the libc guy can't just checkin the kernel changes that suit him most.
Letting the maintainer of ls checkin changes to the VM is not the road to stability IMHO, however I wouldn't be supprised to find that it actually worked in much the same way in FreeBSD land.
Well, there is a
really good high level language for application development: the problem is that there are few good programmers. The language, of course, is Lisp. Extensible, powerful and high-performance: what more could one ask for?
Yeh, silly me, forgetting about all those lisp applications I'm running. xemacs is probably the only one, I personally run, and it's slow, ugly and has more than a few annoying bugs (mainly with the UI). In fact it's so bad I keep looking for ways to migrate from it, but keep whimping out.
Fewer damned parentheses, I suppose:-)
I actually like the parens, but I still don't write any real lisp apps.... and have no intention of starting. Here's a free clue, I didn't learn python because I thought appending commas to the end of print statements was a great idea... I learnt it because of pygtk.
When there's a free (as in perl and python) lisp language that's useful for doing things in... those things will start to be done in lisp (I had hopes for rep, but that turned out not to be... again).
Somehow, I don't think liability insurance is an adequate answer, either. Who's going to underwrite the risk that we'll turn our solar system into a black hole the next time we fire up the Relativistic Heavy-Ion Collider? Are we going to be in good hands with Allstate then?
I will. You pay me $10 a month, and I'll pay for any damages you can think of if someone turns our Solar System into a black hole.
djbdns does support caching. Anyway, you should be using different programs to cache and serve up authoritative data. Some of BIND's security problems were caused by its combination of cachine and authoritative data, so that is no longer a recommended configuration.
I remember it being non-trivial. BIND has had more than a few code problems, so this is more an indication of experience/talent/awareness/whatever than which features are good. And it might now no longer be "recommended", but only the largest organisations follow that recommendation (hell look at the article, over 50% of the bind servers, over a third of all DNS servers, are returning packets with the RA bit set).
And, to be frank, a lot of recommendations to do with DNS are of the form. X has traditionally been done way Y, so it's recommended you do X way Y... no sorry we don't have any real data to back that up.
So what is the general concensus? Do people really find Python to be as time-consuming as C/C++? I don't see how that's possible, but it can't hurt to ask.
One of the big problems I've seen is when most of the code you are using is in a C python module. For instance gtk. What happens then is that the C interface is much better documented, and often better designed (going from gtk1.2 to gtk2.0 in python was a much bigger change than for C code).
And on top of all that, if you screw anything up the C code will go wrong in the exact same way (but it's a much bigger pain to debug the python interpreter SEGVing than if you had written your code directly in C).
And then you have a dep. on a bunch of python stuff which makes distributing it much harder... I used liferea for a long time over straw because I just couldn't satisfy the deps. for straw (and pertinently straw was buggier).
Sure, you get some benifits... syntax for creating arrays/dicts is very compact which can make certain interfaces easier... and you don't have to care about the lifetime of some of the objects. After having done both, I might use python again for simple GUI apps.... but it's not as clear cut as you want to suggest.
Microsoft believes wholeheartedly in Capitalism -- pure,
unrestricted Darwinistic Captialism. And they're very good at it. That is something that few/.ers will ever understand.
Emphasis added.
And it should be obvious from the emphasis how untrue that statement is. They want govt. protection so that nobody else will "steal their IP"... thus. cloning win32 and completely destroying their monopoly pricing scheme (as would happen in an unrestricted market).
However they don't want any of the govt. protection for anybody else, so that those other companies/people can make a living.
Out of curiosity, what countries include the tax in the advertised price?
Most of those not in north america. It was a big shock to me, having lived in the UK that when the item was marked at $1 that wasn't the amount you needed to pay.
The world does not exist where we could remove copy protection and still expect to make sales. Don't try to pretend that it does - that position is clearly naive.
That the copy protection is easily broken is irrelevant
Why is this "irrelevant". You are saying that you can't charge $5000 per copy unless you have copy protection, although you admit that the copy protection doesn't actually protect anything.
I presume that your customers actually buy a service for that $5000, which happens to include a CD with a somewhat non-random makup of 1's and 0's. Those that would pirate it don't get the service, which is the real pain for them.
Slashdot Mirror
And python and perl aren't? At least I can write a secure "rm -rf" in the later two ... in Java security is sacrificed for "portability". And it even fails at that due to every deployment of Java I've seen having the most fucked up env setup scripts I've ever seen, which make it a major PITA to move from one machine to another.
No, I'm not. As I said, I can only assume that you have screwed up your locale settings on the machines you had to do it manually on (Ie. the non Red Hat boxes). See bash NOTES point 13, where it repeats what I've told you. Even searching for "en_US locale" on the debian lists gives: this message, among others, which confirms what I told you. Although the most recent message seems to be advocating breaking collating in the locale because of people like you.
All you have proven is that you can't listen, and can't configure you locale settings (or, I guess it's possible, that you've just broken your machines in some more fundamental way ... whatever).
Why? I can only run one editor at once, so should I not be able to install two? I can only run one web server on the default port at once, so should thttpd refuse to install if apache-httpd is there?
Debian testing also don't guarantee security updates, and more than one remotely accessible app. has gone months without known security updates. The debian response is that this is expected, and people using testing shouldn't be using it in production (that's what stable is for) and should be closely following development so they can install from unstable/stable if they need to.
Right, because debian is so much more usable. I didn't say FC1, I said Linux circa. FC1 ... Ie. Linux that was available at the time the comment was made. And it wasn't said that Linux wasn't ready for the desktop, just that it wasn't ready for the average consumer (Ie. mom's who have their quilt design package, Pop's who have MS train simulator, little joey who plays games). Red Hat have more than a few customers using it on the desktop already, this is not the same thing.
Run "locale", certain env. variables override others. I can't say I'm shocked that you've set it up incorrectly. Or don't bother, just run...
...then you don't have to bother replying.
I rarely care about having the very latest perl modules, and if I do ... I can just update the srpm from red hat and upgrade, this is even easier than creating new packages. Or maybe you mean what about updates? That needs to be handled either way ... unless you're insane enough to have some auto update CPAN code?
Yes they can both run, but they don't clash ... for instance my iptables init.d file contains...
And if you reply, without checking your facts in a reasonable way, I doubt I'll bother replying ... it should be obvious to anyone reading this thread that you appear to be clueless.
It does, gcc=2.95.x, bind=8.x.x, (Ie. historic). Unless you want to use "unstable" ... which is errr. unstable. And if you do ... fine, what do I care, you can use slackware if you want ... but that sure as hell isn't more usable than Fedora by any measure.
I think you are confused. I haven't done that for years, with Red Hat and Fedora. Just as I'm sure you don't use dpkg manually with debian.
So you are suggesting that Linux circa. Fedora Core 1 could win a viable majority of the consumer market? Or maybe that knowingly lying about it to people is a good idea (actually given your responces, if the shoe fits...).
I can see you are confused, so I'll put this in bold: That is correct behaviour for en_US. Here's a free clue, in en_US the layour of the characters is "AaBbCc...Zz" you did the character group [A-Z] and so got the entire alphabet excluding "z".
Here's another free clue, if you set your locale as en_US on debian stable ... it does the same thing. Of course debian doesn't set the locale for you on install/upgrade, just as it doesn't do many other things ... but that's fine if you know what you are doing.
Sure, I can see that it'd probably be better to not depend on "the X libraries". But, to be frank, it's almost impossible to do that on debian too. Hell, debian's exim package depends on a whole bunch of crap I don't want ... but I think I can sacrifice the 1 of disk space in both cases and just not care.
No, you said that not all CPAN modules are in rpm packages from Red Hat ... Oh my god, news at eleven. Your "solution" to this is to completey remove rpm from the picture ... my solution is to spend the 2 minutes to make rpms for the missing CPAN modules I need.
Why would you do that ... as I said, it works. Put CD in drive, reboot, choose upgrade.
I think you are confused (I'm seeing a pattern here), iptables and ipchains are both installed ... but it's not possible to have them both "active", if you have ipchains rules then they will continue to work. If not, you can create iptables rules ... you can't have both.
Hahahaha. But whatever, I'm up for taking 5 minutes to do some simple troll killing.
1. Rpm isn't perfect, but it's far better than you imply. It almost never crashes, and fixing an rpm DB is very painless.
2. *shrug*, debian is at least as bad (I had to install xemacs from tarballs throught "potato" because the package was so broken). Plus you get joyful things like the modem defaulting to 1970s speed on debian. And with Red Hat I won't have to wait 5 years for an update ... plus this is Java, on the Free beer product. So what, I don't care and I'm pretty sure jar will just work in RHEL 3.
3. Yes, I have. And I much prefer rpm/yum over dpkg/apt.
4. Err, yeh. Whatever. Pass the crack pipe etc.
5. Please learn to read, "I would argue that ... for that classic consumer purchaser, it is my view that (Linux) technology needs to mature a little bit more." is not close to what you implied.
6. I assume you are running in an en_US locale so grep is doing what you told it to. How terrible for you.
7. By "X" I presume you mean some of the libraries, my how terrible this bug must be for you at todays prices this has to be at least 1 of disk space.
8. You can break your machines however you wish, I fail to see how that's Red Hat's fault though. All my perl stuff is in RPM format, and life is good.
9. This is complete crack, it's at least as easy as upgrading debian ... the big difference being you need to reboot on Red Hat, which is a nice propert of debian ... but hardly worth the 5 year waiting period.
10. Oh woe is you, another 1 of disk space on backwards compatability.
Then you have to realise that you don't get guaranteed security updates with testing, and indeed some well known remotely available packages have gone months before the security errata rolls into testing.
Debian stable isn't bad, if you don't mind being 3-5 years behind the curve, and indeed in some cases I don't but it's sure as hell not my first choice.
But, hey, you do what you want. If you don't screw it up too bad, well done ... and when^Wif you don't, I can come in and offer your company a solution.
Riiight, feel free to pass the crack pipe around so everyone can get a bit. Unless you don't consider the linux kernel, glibc, binutils, GCC, elfutils, libxml, glib, gtk, metacity or dict "important" ... and that's just off the top of my head where at least a significant portion (in a few cases, basically all) of the developers are directly employed by them. And if you include useful stuff which isn't included in every major distro. or include stuff they wrote but don't maintain now the number goes up a _lot_.
You could probably argue that in some cases the employees wrote those things "outside" the company, by either spending time on it before they were employed or time when they might otherwise call non-work time. But I'd retort that basically the same thing happens in other companies, it's just more transparent with Red Hat.
That's more like three than two, two is where you generate a large random file that hashes the same as the iso (thus making downloads look ok, but actually be bad). If you can start with some known data, and then append something to make the hash be what you want then, yes, that's almost as bad as starting with the original and altering it but keeping the hash.
You also have other problems like the .iso you end up with really needs to be the same size and you probably need to break both MD5 and SHA-1 on the same file, which is probably much harder.
Yes, in gcc, you can. See builtin_expect().
Every MS tech that I've ever heard speak about it has said that MS did their own stack from the ground up. I know Linux did their own stack from the ground up. Why repeat such obvious lies?
That's funny given that apache uses one task per connection, and kqueue/epoll/etc. only help when you have many fds to get events for and most of them are "idle". In fact I'm pretty sure Apache uses blocking read/write calls.
Oh, my god stop the press. Not having to re-invent the wheel is seen as a benifit. Why is it that all these so called "great lisp hackers" can't understand this one simple fact. The reason I learnt perl was that I could just do...
...and have it work (without having to write a Regexp library), in a similar vein I wouldn't have learnt python if I couldn't do multiple https GET/POST calls in a couple of lines of code keeping cookies over the session.
I've never written in Java, and have no intention of doing ... but I can see that having a massive std. library is a major benifit over lisp/scheme etc.
I don't think that's true. Possibly more weight was given to RH/SuSe ... but then they have more users. There are Debian users/maintainers on the LSB.
Yes, third party packaging was defined as a very old version of RPM ... but then you have to take into account it is debian with deb's on one side and RH, SuSe, mandrake, caldera, turbo Linux, etc. etc. on the other side with rpms. And most of the differences at that level are aimed at proprietary third parties, everyone in the Open Source world just makes two versions a deb for debian and an RPM for everyone else.
Everything else, like ABIs etc. are mainly lowest common denominator and hence tend to favour Debian, if anything.
When the libc5 -> glibc move happened I was still compiling my own kernel and libc. I think I had a copy of the Applix suite ... but I can't remember. And even then, it wasn't too bad you could have old and new apps. running in the same places ... you just had problems with shared libraries (but even then, there was much less shared library usage ... everyone used libc, X stuff used libX* and libc and some other stuff used a couple of others, like zlib) -- you could do new version of 99% the shared libraries by compiling less than 10 tarballs.
That's very different to today. C++ didn't even come close, mainly because not as much stuff used it ... and also because vendors did recompiles as groups (and the older versions in the same place as before continued working).
Trashing ABI compat., at this point, would be orders of magnitude more painful. Every app/lib would need to move, with copious hacking/wrappers to the binaries and even then it would fail randomly for years IMO.
However they have demonstrated backwards compatability, a great deal more than the Linux community has had to do. And they paid everyone, thus invoking the golden rule. Certainly large companies buying AMD64 boxes will be buying them so they can run their x86 Oracle etc. better than before.
That's fine, they can do whatever they want ... they can just say fuck everyone else we'll do it our way. And everyone else will ignore them.
Define "crap software" certainly compiling anything on Debian that just used libc and the kernel can be a crap experience ... I've found/reported compiler bugs over 18 months ago, that were just responded with "sorry, no man power ... don't do that".
No Open Source product "has to release" to make money. Most of the good ones realize that releasing more than once every three years is a good thing though. And more than a few think that having newer, faster tech. like a decent compiler, threading, LVM, GUIs etc. isn't such a terrible thing either.
Grow up.
...which is why it's incompatible to everyone else. Look sparc64 had (has?) a 32 userspace for a long time. 32 bit apps. can run faster (I think they often do, actually), with a 64bit kernel ... and they are a hell of a lot smaller, on disk and in memory. And AMD explicitly wanted the layout so you could just use the AMD64 as a faster x86 for a while, if you wanted to ... then upgrade at some later point (but still run your 32bit oracle etc. ... just as you did before).
Possibly, but it's not backwards compatible ... and it's not compliant with the LSB. For instance it's not hard to create an new x86 ABI that's faster (technically superior) than the current one, but the fact that it's not compatible with the one everyone else is using would be a pretty big reason to ignore it, if someone did one.
In another way I, personally, probably would prefer all the 64 bit stuff in /lib /usr/lib etc. and have some /usr/i386-chroot directory tree that I run all my old 32 bit apps under ... but, again, the fact that it's not what everyone else would have is a big reason for me not to do that.
As I understand it, what you said is not true. The LSB requires that amd64 have the 64 bit libs in /lib64 and the 32 bit ones in /lib ... mainly because that's what AMD wanted (the intention being poeple could/would buy/use AMD64 as a fast 32bit CPU and then at some point "upgrade" to 64bit).
Debian has refused to do this, thus the amd64 "port" of debian isn't LSB compliant.
So what are you complaining about ... the fix seems obvious to me. Just bandwidth limit all RSS requests connects between x:00:00 and x:01:00 to 1KB/s or something. Or just block those IPs for an hour. This isn't html, if I happen to open my RSS reader during that window one day ... so what. I'll get it the next, or later that day if I open it again.
All the retarded RSS readers get what they deserve, sucks to be them or their users ... the coders will work out how to stop being so retarded, or their users will work out how to find an RSS reader written by someone who has.
I'd also bet that you'd only need to have this policy for a while, and then the problem will stop (or so be much smaller you don't care anyway).
No, it's not, from rfc1035.txt...
This is a cute soundbite, but real life isn't that clear. For instance project gutenberg has lots of substance, the appearance is so horrible that the quality is severly reduced.
But that isn't The Linux libc, it's one of a few choices ... although admitedly the most popular. Other choices include uClibc, klibc and even dietlibc.
And the libc/kernel actually have a pretty well defined boundry, so it doesn't seem strange at all to me. Actually I see the "discussions" between the kernel and glibc maintainers and can't help but thinking that a better solution to a problem is found because the libc guy can't just checkin the kernel changes that suit him most.
Letting the maintainer of ls checkin changes to the VM is not the road to stability IMHO, however I wouldn't be supprised to find that it actually worked in much the same way in FreeBSD land.
Yeh, silly me, forgetting about all those lisp applications I'm running. xemacs is probably the only one, I personally run, and it's slow, ugly and has more than a few annoying bugs (mainly with the UI). In fact it's so bad I keep looking for ways to migrate from it, but keep whimping out.
I actually like the parens, but I still don't write any real lisp apps. ... and have no intention of starting. Here's a free clue, I didn't learn python because I thought appending commas to the end of print statements was a great idea ... I learnt it because of pygtk.
When there's a free (as in perl and python) lisp language that's useful for doing things in ... those things will start to be done in lisp (I had hopes for rep, but that turned out not to be ... again).
I will. You pay me $10 a month, and I'll pay for any damages you can think of if someone turns our Solar System into a black hole.
I remember it being non-trivial. BIND has had more than a few code problems, so this is more an indication of experience/talent/awareness/whatever than which features are good. And it might now no longer be "recommended", but only the largest organisations follow that recommendation (hell look at the article, over 50% of the bind servers, over a third of all DNS servers, are returning packets with the RA bit set).
And, to be frank, a lot of recommendations to do with DNS are of the form. X has traditionally been done way Y, so it's recommended you do X way Y ... no sorry we don't have any real data to back that up.
One of the big problems I've seen is when most of the code you are using is in a C python module. For instance gtk. What happens then is that the C interface is much better documented, and often better designed (going from gtk1.2 to gtk2.0 in python was a much bigger change than for C code).
And on top of all that, if you screw anything up the C code will go wrong in the exact same way (but it's a much bigger pain to debug the python interpreter SEGVing than if you had written your code directly in C).
And then you have a dep. on a bunch of python stuff which makes distributing it much harder ... I used liferea for a long time over straw because I just couldn't satisfy the deps. for straw (and pertinently straw was buggier).
Sure, you get some benifits ... syntax for creating arrays/dicts is very compact which can make certain interfaces easier ... and you don't have to care about the lifetime of some of the objects. After having done both, I might use python again for simple GUI apps. ... but it's not as clear cut as you want to suggest.
Emphasis added.
And it should be obvious from the emphasis how untrue that statement is. They want govt. protection so that nobody else will "steal their IP" ... thus. cloning win32 and completely destroying their monopoly pricing scheme (as would happen in an unrestricted market).
However they don't want any of the govt. protection for anybody else, so that those other companies/people can make a living.
Most of those not in north america. It was a big shock to me, having lived in the UK that when the item was marked at $1 that wasn't the amount you needed to pay.
Why is this "irrelevant". You are saying that you can't charge $5000 per copy unless you have copy protection, although you admit that the copy protection doesn't actually protect anything.
I presume that your customers actually buy a service for that $5000, which happens to include a CD with a somewhat non-random makup of 1's and 0's. Those that would pirate it don't get the service, which is the real pain for them.