The point is that all the information that feeds into IBM is already publicly availble.... Of course, I suppose WebFountain could be used to construct a membership list by scanning people's home page's to find out if they say that they're a member, but again this is publicly declared information.
But that's it, you can't just say "all I did was collect public data" so it can't have privacy concerns. It's obviously still got them (unless your collector is useless).
For instance, I might say on/. that I think Fox "News" are extreme right wing liers and/or that a women's right to choose is a good thing... and I might have links from my/. page to my website... and I might be interested in photography and publish photos on my website of places near where I live.
But I'm pretty sure if someone said had a list of names and addresses of "unborn killer sympathizers", I wouldn't want to be on it.
And I'm not saying that it's obviously bad, there are obviously a lot of good uses of information agrregation... you just don't get to not have the discussion because "hey, all I did was republish".
Linked lists require links -- this puts pressure on the L1 cache.
I said facts, not theories. Yes, I know all about cache and his friend random access. Maybe you'll take a noticable cache hit when moving between nodes... and yes, certainly doing memcpy() over a single large block X will be faster than doing it X/20 times for 20 byte nodes (20 was the figure given in the IBM "research" article). But that doesn't take into account the time taken to call realloc() each time to expand the large block... or the amount of space wasted if you have a large amount of data followed by mostly small amounts of data... or the sharing that is possible in a node based system (thus almost eliminating the cost of copying).
And I did provide the simple benchmarks (which showed that with sane node sizes the vector approach is better than realloc() + memcpy()), and code for somewhat more complication cases that try to model simple network IO applications (which show the single block of memory is only competitive when you use more memory and add complication to the algorithum to reduce copying... or use lots more memory).
But feel free to prove me wrong, I'd certainly study anything you came up with. And yes, I'm taking the csv code into account... on normal input the node based code was within 50% IIRC, and on "difficult" code it was over 100% faster (again IIRC)... and your code was a lot more hand optomized.
If you amortize the time the GC spends in collection over the allocations, the average allocation isn't that much slower than the corresponding malloc/free. Best of all, the gap is shrinking. Soon, GC may be FASTER overall than malloc/free in many real-world situations. It obviously depends on memory usage patterns and collection strategies, but it is starting to happen.
I've heard that for years, it's yet to be true for the general case... and most people doing manual allocation don't call malloc/free for every single grow/shrink operation. The caching slab allocator was put into solaris a long time ago now.
If you're using GC, your program doesn't have to do all of the bookkeeping anymore.
The keyword being all, yes you can sometimes just completely forget about designing how you use memory and everything "works". However sometimes those bits of memory have other resources associated with them.
An L1 cache miss costs around 4-10 cycles; an L2 miss can cost 100-400 cycles; a page fault costs millions. The CPU time spent in garbage collection can become insignificant when compared with storage access time.
You seem to be under the impression that running the GC isn't going to blow your cache... why is that?
But compacting GC implementations are starting to take things like that into consideration when they collect, and they rearrange the memory of the process to maximize cache hits and minimize memory waste.
And the GC knows when to move memory, and when it's just wasting CPU/cache... how? It's fairly simple to have double pointers (both win32 and MacOS9 use HANDLE types a lot IIRC). The big problem is working out when you can/should move them.
GCs usually collect on a separate thread. That means that with a properly designed collector, while your program is blocked on IO or waiting for user input, the GC might be cleaning up the heap on a low priority thread. With luck, your main thread might NEVER actually be interrupted for a collection
If you actually want threads... which many of us don't. It also seems to think that cross CPU cache invalidates are free (accessing the same data from more than one CPU -- this can have a massive cycle cost), and that the GC does some kind of magic locking which will never affect the application.
It's also amusing that, by definition, it means that as your application does more work (and hence needs more CPU) it is guaranteed to not get it... because you will then suddenly start fighting with the GC thread.
While I don't think GC is quite to the point where it is free or beneficial to the performance of the average application, it is a lot less harmful than most people think.
It's my experience that the people who think GC is expensive generally know what they are talking about, and are in the minority. Most people either don't need to care (GC is good enough for them -- fair enough, I've written things where I used perl and didn't need to know how it allocated), or just don't care.
There are other ways of managing memory than just giving up and saying well the GC will save me. Vstr, which is a decent implementation of what the IBM article was trying to say removes almost all the allocation/deallocation headache when dealing with byte data... but it's still controllable and predictable.
Comprehensive, that's for sure, but the examples look like it's also reinventing FILE* in the io_* API.
The io_* API is part of the examples, and not in the library itself. But it's a pretty small wrapper over what's in the library... and, yes, the library itself was designed so it could do non-blocking IO (which FILE* can't). So in that regard, yeh, I don't tend to use FILE* anymore.
glibc's fmemopen() moots most of the IBM article, I think, but since I don't code exclusively in a glibc environment... Grrr... If only POSIX specced out FILE* a bit tighter...
Yeh, fmemopen() would have helped a lot. Esp. if you could have implemented asprintf() via. it (Ie. expanding memory regions). But it's completely unportable (and I wouldn't trust even the glibc implementation... as hardly anyone uses it). But even then vstr_* is very nice in that it crosses both a IO stream like API with a string API. So you can get data from an fd etc. and immediately split it, or search for something without having to copy it into a string API. Then again, I'm biased:).
Representing in memory object sizes with "long int" *sigh*.
FWIW, this is not as trivial as one might think [snaip...] I figured that using a void * to store memory range offsets would be sufficient. Problem is, C doesn't define some operations that I needed to do (like modulus) on pointers. So I get the possibility of casting to...an int of some sort. Grr. It took me quite some time to run across intptr_t, which is an integer type guaranteed to be able to hold a pointer.
Well I meant the sizes, not the actual pointers... his skeleton API doesn't seem to need to get the values of pointers (which, as you say, you'd want intptr_t or unsigned long/uintmax_t etc.). But I was talking of the fact that he has "totalLength" defined in the struct, as a "long int" instead of say "size_t" or at the least "unsigned long".
Also linked lists are very prone to leaking and very hard to figure out which one to free first.
So you a) have the library code do that... and b) have lots of tests. Of course you want to do both of those for something using a single block of memory too, and if you want it to be efficient it usualy does something clever to avoid copies... and so is probably more likely to screw up and use/deallocate the wrong thing. As for leaking memory, that's pretty much built into the design with a single block of memory model, unless you want to keep calling realloc() to shrink the buffer (then you just blow the fragmentation of malloc to hell -- which if you're lucky will just make things slower).
The "idea" of the article wasn't bad, it's just a very bad description of the proposed solution... and a couple of years too late.
The fundamental problem is that this sort of thing needs to be done at the C library level. And if it's not done in a flexible fashion, you end up with a library call that rarely gets used. Anyone used hsearch() lately?
Take a look at, Vstr I think it's pretty flexible... it certainly has much better researched documentation than the content for this IBM "research" article.
The article basically proposes a very bad implementation of Vstr, most of the advise was extremly simplified at best but more likely just uninformed: an "efficient" abstract buffer that mixes shorts and pointers -- words almost fail me, how to solve the problem of "what do you do with the data when it's all in the buffer" -- "let's just copy it back out again (hey whats a couple of extra copies between friends). Representing in memory object sizes with "long int" *sigh*.
Vstr is LGPL, has actual benchmark data behind the block sizes it picks, has an extensive test suite... and has documentation for the many functions that come with the library (including a fully compliant printf like function). Of course, I don't have a PhD... but after reading this, you might well count that as a plus too
This all pretty much "just works" now, and has done since gtk+-1.0.0 (modulo bugs). The only real annoyance is that if you are saving you have to get rid of the suggested name for the file to use the completion... which is annoying. But I use the completion all the time for open. And I would have been a lot more annoyed about the crappy default fileselector without completion.
/usr/bin/lua is 140k... a simple compile of the example nasal binary is 60k. lua also links to a whole bunch of extra libraries. wc -l of the.c files shows lua to have 13.4k and nasal 3.4k. Running lua gives a default prompt and takes 6.2Meg VSZ, 848K RSS. Running an infinite loop nasal script (it doesn't have an interactive mode in the example binary) gives 1.7Meg VSZ and 456K RSS. Hell tinyscheme is less than lua in every regard and is pretty close to a real language.
And it's much easier to tweak nasal (because it's so much smaller), so if you don't need bits you can just rm them.
When I was answering this question, I ended up looking at nasal. While not perfect, it was the closest to what I wanted... and was under a compatible license (LGPL). But then I wanted something small, lua is way too big.
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release.
The Debian FAQ doesn't call security patches to unstable "updates" because that's not what they are.
My point exactly, that's not what they are... because they don't guarantee they'll provide patches.
They're bug-fixes that prompt an incremented release number.
Sure, whenever the next package update happens... and assuming nothing is broken in unstable so you can't upgrade... then you can upgrade to the next version which should have the fixes in. However note that package updates happen much slower than security updates (for instance upstream is often not told before an issue is made public like distributions are), and updates will often contain extra features/bugs (including possible depenancy updates, with extra features etc.) unlike security errata from most distributions.
You like debian, and that's fine. But don't say it provides something it doesn't... if you use anything but stable then you need to be able to make your own security errata (or work around it) if it's required. This is great for a developers workstation, but terrible for servers or people who can't fix problems on their own.
Sep 28 01:33 Linus Torvalds releases 2.6.0-test6 with do_brk() fix
Oct 02 05:18 Marcello Tosatti applies do_brk() boundary check
Nov 19 17:00 Attacker logs into klecker with sniffed password
Nov 19 17:08 Root-kit installed on klecker
Nov 19 17:20 Attacker logs into master with same sniffed password
Nov 19 17:47 Root-kit installed on master
Nov 19 18:30 Attacker logs into murphy with service account from master
Nov 19 18:35 Root-kit installed on murphy
Nov 19 19:25 Oopses on murphy start
Nov 20 05:38 Oopses on master start
Nov 20 20:00 Discovery of Oopses on master and murphy
Nov 20 20:54 Root-kit installed on gluck
Nov 20 22:00 Confirmation that debian.org was compromised
Nov 21 00:00 Deactivation of all accounts
Nov 21 00:34 Shut down security.debian.org
Nov 21 04:00 Shut down gluck (www, cvs, people, ddtp)
Nov 21 08:30 Point www.debian.org to www.de.debian.org
Nov 21 10:45 Public announcement
Regarding the security record of various distributions, I don't think the commercial ones will tell us if they are hit, unless it becomes obvious from outside. Who knows how often they have been compromised? Gentoo just announced a compromise, perhaps based on the same brk() bug.
That's nice bruce, you've just insinuated that it's something that happens to everyone... without having any evidence. And like when Microsoft says the same things about viruses etc. I'm not going to believe you. fact 1: debian has way more people who log into their servers than any comercial distro. The person got in through a sniffed passwd from a real user, then got root. fact 2: You can log into real machines for debian with just a username/passwd, I doubt this is true for any comercial Linux company (and yes I do work for one).
The really impressive thing about the Debian breach was that it happened at 5 PM, they had detected and confirmed a breach and had the sites shut down by 10 PM, they announced the breach at 10 AM, and they did the forensics and found an unsuspected exploit within about a week. I dare you to show me a commercial Linux distribution that has been that timely.
That's a nice story, but from debian-announce...
Sep 28 01:33 Linus Torvalds releases 2.6.0-test6 with do_brk() fix
Oct 02 05:18 Marcello Tosatti applies do_brk() boundary check
Nov 19 17:00 Attacker logs into klecker with sniffed password
Nov 19 17:08 Root-kit installed on klecker
Nov 19 17:20 Attacker logs into master with same sniffed password
Nov 19 17:47 Root-kit installed on master
Nov 19 18:30 Attacker logs into murphy with service account from master
Nov 19 18:35 Root-kit installed on murphy
Nov 19 19:25 Oopses on murphy start
Nov 20 05:38 Oopses on master start
Nov 20 20:00 Discovery of Oopses on master and murphy
Nov 20 20:54 Root-kit installed on gluck
Nov 20 22:00 Confirmation that debian.org was compromised
Nov 21 00:00 Deactivation of all accounts
Nov 21 00:34 Shut down security.debian.org
Nov 21 04:00 Shut down gluck (www, cvs, people, ddtp)
Nov 21 08:30 Point www.debian.org to www.de.debian.org
Nov 21 10:45 Public announcement
Actually, I base my judgment on Amtrak not being profitable using GAAP, or, generally accepted accounting principals.
I know what GAAP is, but that is presumably excluding govt. monies. And as I said I didn't argue that Amtrack wasn't profitable atm. if you did that. I said that so are all the car manufactures (massive subsidies for both factories and the obvious road works that the govt. pays for). And most or all of the Air Lines would be in Chapter 11. if it weren't for subsidies.
Well, if you are just going to say people don't want "debian-obsolete, debian-broken, and debian-by-another-name" without any supporting reasons, we're not really having an argument, it's just abuse. Try to put a logical argument together.
But it's certainly not all "logical" in the real world. People have tried installing potato and/or woody and just aren't going to try that again without a lot of evidence of why they should. There's also the fact that they'll have been using RHEL or SuSe etc. for a couple of years when UserLinux 1.0 comes out and they'll type "service named start" and they'll get "command not found".
But I guess this will just be the baby steps when they try and compile their code and realize that even though it says "gcc" and "glibc" in UserLinux it's not even remotely what they've been getting from RHEL.
Really, the only way it'll stand a chance is if you have half of the RHEL rpms repackaged as.debs in your custom repo. And I'd imagine that most debian developers wouldn't appreciate that being associated with them. There are ways to offer a real competitive solution for RHEL... but something based on debian isn't it IMO. You want something with choice, lots of choice... esp. allowing the choice of being pretty close to RHEL, but also making it easy to choose to change certain parts without affecting the entire thing. Certainly choice needs to override RMS' political goals.
And before you accuse me of wanting to revitalize Debian, you should attempt to make a case that it has lost vitality.
The case is usually made that it never had it, certainly the only version that has security updates is often a couple of years behind what the rest of the distributions are using (and I know you've said that "unstable" has security updates but that isn't what the debian FAQ says and anyone stupid enough to run unstable is going to go back to Red Hat so fast it won't be funny).
Well I'm sorry, but I don't see where I was comparing Amtrak to automobiles at all.
I was trying to refute the poster who said that Amtrak "makes" millions of dollars per year. I was taking that to mean that he thought Amtrak profited millions of dollars. Amtrak as a distinct entity loses tons of money each year. I was only attempting to address that single issue.
You are saying "Amtrack isn't profitable" and you are saying it based on the fact that they recieve money from the federal govt.. Ok, fine, if that's how you want to define profitable. But you now need to apply the same formula to the car industry, and the air lines... and ta da they are all "unprofitable" of course people still "need" to travel.
This is like both the PS2 and gamecube getting subsidies but saying it shouldn't be counted for one of them.
Log4J is still a lot more popular than 1.4 logging.
Yeh, I'd heard that from friends who use Java. The point there was that the OP seemed to be suggesting that if a J2EE container came from the Apache group it would suddenly be used by everyone, because everyone loves the Apache group or the license would be so much better etc. My point was that even though Java people I know say log4j is better than 1.4 logging Sun didn't just use what apache produced..
if you go back a couple of years and look at JBoss you would have said without help from somewhere, they would never catch up with BEA or Websphere. They haven't really, but they have definately narrowed the gap (maybe really close on WebLogic). What JBoss did manage to do is cut out all the small players.
This is exactly what Linux did, things like ConvexOS died out very quickly. Then it seemed obvious that BSDi couldn't last... and eventually SCO and now Solaris.
The second commer doesn't have to be that much better actually. We're talking Java here, not kernels.
I'm not convinced, people don't use kernels they uses OSes. POSIX is a spec too, and certainly back in the day (now things like TuX and divergant extension APIs make it somewhat harder) Linux to FreeBSD were simple to move between. But Linux was there first, it had the mindshare and hence the developers and users. Red Hat is shipping JBoss now, people who don't know anything about J2EE containers (like me:) know that JBoss is one. And as Geronimo improves so will JBoss.
I think Geronimo has a greater chance of causing havok in the J2EE arena.
Err, somethign that won't be at the level of JBoss for another year or two, at least. Why do you think so... the license, AIUI companies are already shipping JBoss as the "cheap" solution... maybe they'll all switch, but that isn't real growth.
ASF has a history of making very popular software packages, especially Java related.
While I'm not big on Java, the above seems a little rosier than life IMO. ASF do apache-httpd, and that is obviously very poopular... you could also imply that APR is because of that (although I'd disagree, peolpe only ship it because apache-httpd needs it). Ant is somewhat popular, and log4j might be considered to be as popular as apache-httpd in it's specific niche... but note that the Java-1.4 logging package looks nothing like it.
But looking at all the other projects, I haven't even heard of half of them... www.apache.org looks more like sf.net everyday. As always with OSS I think the second commer will need to be much better to overtake what's there.
too have seen and spoken to RMS personally, and I have no objections to his hair, dress or speech. His speech is well-thought out and spiced with real world examples of propriety software licences hindering the practical solution of problems. All the jokes on slashdot about him being unwashed, being a pinko and all that is just plain cruel. To the fucking moderator who thought that funny, I'm seeing you in metamod.
Well, that's good and gives me some hope. But I've heard more than a couple of first hand accounts of him cutting his toenails at the dinner table or not having showered recently to be dismissive of others saying the same (however I would presume that he wouldn't do that on "the stand").
AIUI they "sometimes" provide them, but make no guarantees. Which might be fine for developers (my friend with the cvs security problem using testing just compiled his own version for those couple of months)... but isn't much use for "normal" people IMO. I'm also not sure how it works in practice, as the updates there for testing seem to be the stable versions... which I thought were behind testing.
Again more ignorance. Try adding this to your/etc/apt/sources/list:
deb http://security.debian.org sarge/updates main contrib non-free
You can replace "sarge" with "testing" if you prefer this.
From "http://www.debian.org/security/faq"...
Q: What is the policy for a fixed package to appear in security.debian.org?
A: Security breakage in the stable distribution warrants a package on security.debian.org. Anything else does not.
Q: How is security handled for testing and unstable?
A: The short answer is: it's not.
Now given that people I know have had to work around security updates not being available for testing for months at a time. Then I'm included to continue in my "ignorance".
Slashdot Mirror
But that's it, you can't just say "all I did was collect public data" so it can't have privacy concerns. It's obviously still got them (unless your collector is useless).
For instance, I might say on /. that I think Fox "News" are extreme right wing liers and/or that a women's right to choose is a good thing ... and I might have links from my /. page to my website ... and I might be interested in photography and publish photos on my website of places near where I live.
But I'm pretty sure if someone said had a list of names and addresses of "unborn killer sympathizers", I wouldn't want to be on it.
And I'm not saying that it's obviously bad, there are obviously a lot of good uses of information agrregation ... you just don't get to not have the discussion because "hey, all I did was republish".
I said facts, not theories. Yes, I know all about cache and his friend random access. Maybe you'll take a noticable cache hit when moving between nodes ... and yes, certainly doing memcpy() over a single large block X will be faster than doing it X/20 times for 20 byte nodes (20 was the figure given in the IBM "research" article). But that doesn't take into account the time taken to call realloc() each time to expand the large block ... or the amount of space wasted if you have a large amount of data followed by mostly small amounts of data ... or the sharing that is possible in a node based system (thus almost eliminating the cost of copying).
And I did provide the simple benchmarks (which showed that with sane node sizes the vector approach is better than realloc() + memcpy()), and code for somewhat more complication cases that try to model simple network IO applications (which show the single block of memory is only competitive when you use more memory and add complication to the algorithum to reduce copying ... or use lots more memory).
But feel free to prove me wrong, I'd certainly study anything you came up with. And yes, I'm taking the csv code into account ... on normal input the node based code was within 50% IIRC, and on "difficult" code it was over 100% faster (again IIRC) ... and your code was a lot more hand optomized.
I've heard that for years, it's yet to be true for the general case ... and most people doing manual allocation don't call malloc/free for every single grow/shrink operation. The caching slab allocator was put into solaris a long time ago now.
The keyword being all, yes you can sometimes just completely forget about designing how you use memory and everything "works". However sometimes those bits of memory have other resources associated with them.
You seem to be under the impression that running the GC isn't going to blow your cache ... why is that?
And the GC knows when to move memory, and when it's just wasting CPU/cache ... how? It's fairly simple to have double pointers (both win32 and MacOS9 use HANDLE types a lot IIRC). The big problem is working out when you can/should move them.
If you actually want threads ... which many of us don't. It also seems to think that cross CPU cache invalidates are free (accessing the same data from more than one CPU -- this can have a massive cycle cost), and that the GC does some kind of magic locking which will never affect the application.
It's also amusing that, by definition, it means that as your application does more work (and hence needs more CPU) it is guaranteed to not get it ... because you will then suddenly start fighting with the GC thread.
It's my experience that the people who think GC is expensive generally know what they are talking about, and are in the minority. Most people either don't need to care (GC is good enough for them -- fair enough, I've written things where I used perl and didn't need to know how it allocated), or just don't care.
There are other ways of managing memory than just giving up and saying well the GC will save me. Vstr, which is a decent implementation of what the IBM article was trying to say removes almost all the allocation/deallocation headache when dealing with byte data ... but it's still controllable and predictable.
The io_* API is part of the examples, and not in the library itself. But it's a pretty small wrapper over what's in the library ... and, yes, the library itself was designed so it could do non-blocking IO (which FILE* can't). So in that regard, yeh, I don't tend to use FILE* anymore.
Yeh, fmemopen() would have helped a lot. Esp. if you could have implemented asprintf() via. it (Ie. expanding memory regions). But it's completely unportable (and I wouldn't trust even the glibc implementation ... as hardly anyone uses it). But even then vstr_* is very nice in that it crosses both a IO stream like API with a string API. So you can get data from an fd etc. and immediately split it, or search for something without having to copy it into a string API. Then again, I'm biased :).
Well I meant the sizes, not the actual pointers ... his skeleton API doesn't seem to need to get the values of pointers (which, as you say, you'd want intptr_t or unsigned long/uintmax_t etc.). But I was talking of the fact that he has "totalLength" defined in the struct, as a "long int" instead of say "size_t" or at the least "unsigned long".
While I agree the IBM "research" article is terrible, the idea behind it isn't.
Actually having donetests and benchmarks. I can safely say:
Care to back that up with some facts.
So you a) have the library code do that ... and b) have lots of tests. Of course you want to do both of those for something using a single block of memory too, and if you want it to be efficient it usualy does something clever to avoid copies ... and so is probably more likely to screw up and use/deallocate the wrong thing. As for leaking memory, that's pretty much built into the design with a single block of memory model, unless you want to keep calling realloc() to shrink the buffer (then you just blow the fragmentation of malloc to hell -- which if you're lucky will just make things slower).
The "idea" of the article wasn't bad, it's just a very bad description of the proposed solution ... and a couple of years too late.
Take a look at, Vstr I think it's pretty flexible ... it certainly has much better researched documentation than the content for this IBM "research" article.
The article basically proposes a very bad implementation of Vstr, most of the advise was extremly simplified at best but more likely just uninformed: an "efficient" abstract buffer that mixes shorts and pointers -- words almost fail me, how to solve the problem of "what do you do with the data when it's all in the buffer" -- "let's just copy it back out again (hey whats a couple of extra copies between friends). Representing in memory object sizes with "long int" *sigh*.
If you are interested in the article, go read this explanation of why you want it for security and this explanation of why you want it for speed .
Vstr is LGPL, has actual benchmark data behind the block sizes it picks, has an extensive test suite ... and has documentation for the many functions that come with the library (including a fully compliant printf like function). Of course, I don't have a PhD ... but after reading this, you might well count that as a plus too
This all pretty much "just works" now, and has done since gtk+-1.0.0 (modulo bugs). The only real annoyance is that if you are saving you have to get rid of the suggested name for the file to use the completion ... which is annoying. But I use the completion all the time for open. And I would have been a lot more annoyed about the crappy default fileselector without completion.
And it's much easier to tweak nasal (because it's so much smaller), so if you don't need bits you can just rm them.
When I was answering this question, I ended up looking at nasal. While not perfect, it was the closest to what I wanted ... and was under a compatible license (LGPL). But then I wanted something small, lua is way too big.
So I guess if you try really hard, you can imagine that BeOS (and Acorn etc.) didn't happen. Alas, I can't.
This is not true, quoting http://www.debian.org/security/faq#testing ...
My point exactly, that's not what they are ... because they don't guarantee they'll provide patches.
Sure, whenever the next package update happens ... and assuming nothing is broken in unstable so you can't upgrade ... then you can upgrade to the next version which should have the fixes in. However note that package updates happen much slower than security updates (for instance upstream is often not told before an issue is made public like distributions are), and updates will often contain extra features/bugs (including possible depenancy updates, with extra features etc.) unlike security errata from most distributions.
You like debian, and that's fine. But don't say it provides something it doesn't ... if you use anything but stable then you need to be able to make your own security errata (or work around it) if it's required. This is great for a developers workstation, but terrible for servers or people who can't fix problems on their own.
Stupid /. eating pre tags...
Sep 28 01:33 Linus Torvalds releases 2.6.0-test6 with do_brk() fixOct 02 05:18 Marcello Tosatti applies do_brk() boundary check
Nov 19 17:00 Attacker logs into klecker with sniffed password
Nov 19 17:08 Root-kit installed on klecker
Nov 19 17:20 Attacker logs into master with same sniffed password
Nov 19 17:47 Root-kit installed on master
Nov 19 18:30 Attacker logs into murphy with service account from master
Nov 19 18:35 Root-kit installed on murphy
Nov 19 19:25 Oopses on murphy start
Nov 20 05:38 Oopses on master start
Nov 20 20:00 Discovery of Oopses on master and murphy
Nov 20 20:54 Root-kit installed on gluck
Nov 20 22:00 Confirmation that debian.org was compromised
Nov 21 00:00 Deactivation of all accounts
Nov 21 00:34 Shut down security.debian.org
Nov 21 04:00 Shut down gluck (www, cvs, people, ddtp)
Nov 21 08:30 Point www.debian.org to www.de.debian.org
Nov 21 10:45 Public announcement
That's a nice story, but from debian-announce ...
Sep 28 01:33 Linus Torvalds releases 2.6.0-test6 with do_brk() fix Oct 02 05:18 Marcello Tosatti applies do_brk() boundary check Nov 19 17:00 Attacker logs into klecker with sniffed password Nov 19 17:08 Root-kit installed on klecker Nov 19 17:20 Attacker logs into master with same sniffed password Nov 19 17:47 Root-kit installed on master Nov 19 18:30 Attacker logs into murphy with service account from master Nov 19 18:35 Root-kit installed on murphy Nov 19 19:25 Oopses on murphy start Nov 20 05:38 Oopses on master start Nov 20 20:00 Discovery of Oopses on master and murphy Nov 20 20:54 Root-kit installed on gluck Nov 20 22:00 Confirmation that debian.org was compromised Nov 21 00:00 Deactivation of all accounts Nov 21 00:34 Shut down security.debian.org Nov 21 04:00 Shut down gluck (www, cvs, people, ddtp) Nov 21 08:30 Point www.debian.org to www.de.debian.org Nov 21 10:45 Public announcementI know what GAAP is, but that is presumably excluding govt. monies. And as I said I didn't argue that Amtrack wasn't profitable atm. if you did that. I said that so are all the car manufactures (massive subsidies for both factories and the obvious road works that the govt. pays for). And most or all of the Air Lines would be in Chapter 11. if it weren't for subsidies.
But it's certainly not all "logical" in the real world. People have tried installing potato and/or woody and just aren't going to try that again without a lot of evidence of why they should. There's also the fact that they'll have been using RHEL or SuSe etc. for a couple of years when UserLinux 1.0 comes out and they'll type "service named start" and they'll get "command not found".
But I guess this will just be the baby steps when they try and compile their code and realize that even though it says "gcc" and "glibc" in UserLinux it's not even remotely what they've been getting from RHEL.
Really, the only way it'll stand a chance is if you have half of the RHEL rpms repackaged as .debs in your custom repo. And I'd imagine that most debian developers wouldn't appreciate that being associated with them. There are ways to offer a real competitive solution for RHEL ... but something based on debian isn't it IMO. You want something with choice, lots of choice ... esp. allowing the choice of being pretty close to RHEL, but also making it easy to choose to change certain parts without affecting the entire thing. Certainly choice needs to override RMS' political goals.
The case is usually made that it never had it, certainly the only version that has security updates is often a couple of years behind what the rest of the distributions are using (and I know you've said that "unstable" has security updates but that isn't what the debian FAQ says and anyone stupid enough to run unstable is going to go back to Red Hat so fast it won't be funny).
You are saying "Amtrack isn't profitable" and you are saying it based on the fact that they recieve money from the federal govt.. Ok, fine, if that's how you want to define profitable. But you now need to apply the same formula to the car industry, and the air lines ... and ta da they are all "unprofitable" of course people still "need" to travel.
This is like both the PS2 and gamecube getting subsidies but saying it shouldn't be counted for one of them.
And how much government money goes towards supporting car travel? So do you consider the car industry to be "unprofitable"?
Yeh, I'd heard that from friends who use Java. The point there was that the OP seemed to be suggesting that if a J2EE container came from the Apache group it would suddenly be used by everyone, because everyone loves the Apache group or the license would be so much better etc. My point was that even though Java people I know say log4j is better than 1.4 logging Sun didn't just use what apache produced..
This is exactly what Linux did, things like ConvexOS died out very quickly. Then it seemed obvious that BSDi couldn't last ... and eventually SCO and now Solaris.
I'm not convinced, people don't use kernels they uses OSes. POSIX is a spec too, and certainly back in the day (now things like TuX and divergant extension APIs make it somewhat harder) Linux to FreeBSD were simple to move between. But Linux was there first, it had the mindshare and hence the developers and users. Red Hat is shipping JBoss now, people who don't know anything about J2EE containers (like me :) know that JBoss is one. And as Geronimo improves so will JBoss.
Err, somethign that won't be at the level of JBoss for another year or two, at least. Why do you think so ... the license, AIUI companies are already shipping JBoss as the "cheap" solution ... maybe they'll all switch, but that isn't real growth.
While I'm not big on Java, the above seems a little rosier than life IMO. ASF do apache-httpd, and that is obviously very poopular ... you could also imply that APR is because of that (although I'd disagree, peolpe only ship it because apache-httpd needs it). Ant is somewhat popular, and log4j might be considered to be as popular as apache-httpd in it's specific niche ... but note that the Java-1.4 logging package looks nothing like it.
But looking at all the other projects, I haven't even heard of half of them ... www.apache.org looks more like sf.net everyday. As always with OSS I think the second commer will need to be much better to overtake what's there.
Well, that's good and gives me some hope. But I've heard more than a couple of first hand accounts of him cutting his toenails at the dinner table or not having showered recently to be dismissive of others saying the same (however I would presume that he wouldn't do that on "the stand").
AIUI they "sometimes" provide them, but make no guarantees. Which might be fine for developers (my friend with the cvs security problem using testing just compiled his own version for those couple of months) ... but isn't much use for "normal" people IMO. I'm also not sure how it works in practice, as the updates there for testing seem to be the stable versions ... which I thought were behind testing.
From "http://www.debian.org/security/faq"...
Now given that people I know have had to work around security updates not being available for testing for months at a time. Then I'm included to continue in my "ignorance".