That log line is not of a kernel crash (we call them 'oops'es, or 'panic's), merely the kernel reporting on a userspace task (Xnest, with process ID 4485) crashing with a segfault (trying to access an invalid/protected address).
Every single reference to a change to the kernel is in terms of a commit id. It's not a case of going out of the way to use signatures, the *whole way* is signatures. It's signatures all the way down to the empty directory before the first commit was performed.
Hence Linus' jape about compression. He's compressed gigabytes of files, changes, and commentary down to 40 characters.
Almost none have the commit rights to the important git tree. Even if they commit it to their own tree, it still needs to be pulled into one of the maintainers' trees, and approved by them too.
So in order for there to be any propagation of any changes we need all these things: - you develop from the tarball - you don't notice the changes that aren't yours - you have a repository that others pull from - those others trust you and don't examine your changes - those others are trusred tree maintainers
So basically it's a non-event. Even those who use quilt always have all the patches fully visable at all times, so you can't hide a change as only changes are visible.
"Thanks to the open source nature of the kernel it is trivial to add a rootkit and make a new tarball." But you've not "added a rootkit". All you've done is make a new tarball with an added rootkit. The *actual* linux source, the git repository, which due to the nature of git is cryptographically signed and distributed/mirrored on thousands of machines round the world, remains completely untouched. And were it to be touched, every other mirror of it would immediately know about the change.
This is tiny, not big. I say that as someone who _regularly_ downloads the kernel. (Three times today, for example, but that's exceptional.)
Strange, when I go to http://fungames.tld/my_games I get a completely different list of games, i.e. a completely different document, from when other members of the site go to it. Your view of the web seems to not have reached the stage where cookies were invented yet.
"IAAL [...] conditions?" The consideration is easy: you get code and I will get any source code if you decide to distribute."
Does "IAAL" mean "I am utterly ignorant of what the Gnu GPL is and wish to display my gross ignorance publicly"? Because that's what you're doing.
This'll be a laugh - show me the line(s) in the Gnu GPL which you think support your absurdly incorrect claim. Pay close attention in particular to whom the source code is to be (offered or) distributed./YAW
And to be pedantic, their statement is also just plain false. Some of us have been running Alpha servers using Redhat, SuSE, Debian, etc. linux since before Gentoo was even founded. Alphas have been 64-bit since day one (1992), as have the Linux distributions on them. (MS released a crippled 32-bit version of Windows for it, but Linux and *BSD have always been the real deal.)
What makes you think that it's better to emulate a 32-bit CPU using a 64-bit CPU rather than another 32-bit CPU? What benefit do you think the 64-bit nature of the Opteron family gives you?
As someone who's worked with 68K-on-PPC emulators, I can assure you that having only a 32-bit host made it _easier_ to emulate a 32-bit target.
Another data point - my 533MHz Alpha emulates a 200MHz Pentium (but of course the Alpha is _4_ years older than the iBook. (1997 vs 2001).
Of course, RISC mimicking CISC is easier than CISC mimicking RISC. The latter is pretty forced to use RAM for all registers, and forced to use RMW for every RISC operation despite the fact that the RISC code has already had to do everything itself as RMW. That's _twice_ the overhead. RMW = read/modify/write, 3 ops typically, where CISCs could often to the same operation in 1 op. So that's a 3*3=9 slowdown compared with how a native compiler would compile the same source code (or a native asm coder would write the code).
It may sound silly, but I'd almost suggest using a decompiler to generate (unreadable, unmaintainable) C source from the RISC machine code, and recompiling it for the CISC architecture. From what I've seen, most decompilers do a reasonable job from code that's actually compiled from C in the first place.
Actually it's not so great - if you're mucking around with different kernels etc. then what you really want is virtualisation, not fast reboots. VMWare, or Bochs, or whatever. At least that's what I'd prefer, YMMV.
Slashdot Mirror
You are apparently the only one who reads the original emails, as the rest of us don't have links to those emails. Cite please.
Not at all, because it's false.
That log line is not of a kernel crash (we call them 'oops'es, or 'panic's), merely the kernel reporting on a userspace task (Xnest, with process ID 4485) crashing with a segfault (trying to access an invalid/protected address).
Every single reference to a change to the kernel is in terms of a commit id. It's not a case of going out of the way to use signatures, the *whole way* is signatures. It's signatures all the way down to the empty directory before the first commit was performed.
Hence Linus' jape about compression. He's compressed gigabytes of files, changes, and commentary down to 40 characters.
Almost none have the commit rights to the important git tree.
Even if they commit it to their own tree, it still needs to be pulled into one of the maintainers' trees, and approved by them too.
So in order for there to be any propagation of any changes we need all these things:
- you develop from the tarball
- you don't notice the changes that aren't yours
- you have a repository that others pull from
- those others trust you and don't examine your changes
- those others are trusred tree maintainers
So basically it's a non-event. Even those who use quilt always have all the patches fully visable at all times, so you can't hide a change as only changes are visible.
What complete bollocks.
"Thanks to the open source nature of the kernel it is trivial to add a rootkit and make a new tarball."
But you've not "added a rootkit". All you've done is make a new tarball with an added rootkit. The *actual* linux source, the git repository, which due to the nature of git is cryptographically signed and distributed/mirrored on thousands of machines round the world, remains completely untouched. And were it to be touched, every other mirror of it would immediately know about the change.
This is tiny, not big. I say that as someone who _regularly_ downloads the kernel. (Three times today, for example, but that's exceptional.)
You're scaremongering, that's all.
If you're attempting to correct others, please ensure that your correction is in itself correct.
Degrees Celsius is indeed an SI unit. It is a derived unit with the Kelvin as its base unit.
http://physics.nist.gov/cuu/Units/units.html
The Royal Swedish Academy of Sciences selects who receives the
laureates in economics.
In contrast to the prizes in physics and
chemistry, whose laureates are selected by The Royal Swedish Academy
of Sciences.
If you wish to draw a real contrast, then
it's Physiology/Medicine and Literature which are selected by
different bodies.
If you're going to try and weasel-word
'handed out', don't bother - they're all handed out by the same body.
Strange, when I go to http://fungames.tld/my_games I get a completely different list of games, i.e. a completely different document, from when other members of the site go to it. Your view of the web seems to not have reached the stage where cookies were invented yet.
hash('secrit'+'salt') is *not* the password when the server has sent you 'NH4Cl' as the salt.
How can you say that the RIAA are not a monopoly?
RIAA members create, manufacture and/or distribute approximately 90% of all legitimate sound recordings produced and sold in the United States.
If that's a not a monopoly, what is?
I hear that The Pirate Bay have an absolutely enormous quantity of RAID. Hoorah for them.
"IAAL [...]
/YAW
conditions?" The consideration is easy: you get code and I will get
any source code if you decide to distribute."
Does "IAAL" mean "I am utterly ignorant of what the Gnu GPL is and wish to
display my gross ignorance publicly"? Because that's what you're doing.
This'll be a laugh - show me the line(s) in the Gnu GPL which you
think support your absurdly incorrect claim. Pay close attention in
particular to whom the source code is to be (offered or) distributed.
Is there a difference?
I can only conclude, then, that it's a trap...
YAW.
Hahah.
;-)
OK, smartarse - of what is 'configurate' a conflation?
YAW.
Nope, at least C looks like C.
HLA looks like, gag... gag... gag, Pascal!
Sorry, gotta go. Must evacuate...
YAW.
I have identical package configurations on my i386 debian box, and my (64-bit) Alpha debian box.
To me, the alpha system is just as full-featured as the x86.
Nicer programming environment too!
YAW.
And to be pedantic, their statement is also just plain false.
Some of us have been running Alpha servers using Redhat, SuSE, Debian, etc. linux since before Gentoo was even founded.
Alphas have been 64-bit since day one (1992), as have the Linux distributions on them. (MS released a crippled 32-bit version of Windows for it, but Linux and *BSD have always been the real deal.)
YAW.
Primality tests for numbers of the form k*b^n+/-1 have always (since Proth's time) been poly time, in fact O(n^(2+eps)).
http://primepages.org/
'proving'
YAW.
2^19232891231089 - 1 isn't prime.
3765761637264764023 divides it.
IAAM.
YAW
This program embarassed the police.
They were obliged to put a sack on his head and piss on him.
YAW
"Imagine this thing optimized for the opteron:"
What makes you think that it's better to emulate a 32-bit CPU using a 64-bit CPU rather than another 32-bit CPU?
What benefit do you think the 64-bit nature of the Opteron family gives you?
As someone who's worked with 68K-on-PPC emulators, I can assure you that having only a 32-bit host made it _easier_ to emulate a 32-bit target.
YAW.
Another data point - my 533MHz Alpha emulates a 200MHz Pentium (but of course the Alpha is _4_ years older than the iBook. (1997 vs 2001).
Of course, RISC mimicking CISC is easier than CISC mimicking RISC. The latter is pretty forced to use RAM for all registers, and forced to use RMW for every RISC operation despite the fact that the RISC code has already had to do everything itself as RMW. That's _twice_ the overhead. RMW = read/modify/write, 3 ops typically, where CISCs could often to the same operation in 1 op. So that's a 3*3=9 slowdown compared with how a native compiler would compile the same source code (or a native asm coder would write the code).
It may sound silly, but I'd almost suggest using a decompiler to generate (unreadable, unmaintainable) C source from the RISC machine code, and recompiling it for the CISC architecture. From what I've seen, most decompilers do a reasonable job from code that's actually compiled from C in the first place.
YAW.
$ uptime
17:44:44 up 439 days, 7:50, 7 users, load average: 1.07, 1.02, 1.00
I think I'll install it some time in 2005, maybe.
Actually it's not so great - if you're mucking around with different kernels etc. then what you really want is virtualisation, not fast reboots. VMWare, or Bochs, or whatever. At least that's what I'd prefer, YMMV.
YAW.
" remember that FFR isn't a commercial website "
What's its domain?
That's gonna be a losing argument.
YAW.