I just think this goes a long way to say that GNU/Linux security sucks, the theory of a thousand eyes isn't true because the eyes aren't looking, GNU/Linux security sucks, FSF is administrated by incompetent boobs (notice that even their pre-hacked backups could be compromised -- um, "offsite backups" anyone?), GNU/Linux security sucks, auditing is non-existent because they can't tell who did what (they'd first need ACL's for this), GNU/Linux security sucks, backdoors can be in open source code, ... and did I mention that GNU/Linux security sucks?
> -----Original Message-----
> From: Scott McCollum [mailto:[email protected]]
> Sent: Thursday, August 14, 2003 5:14 PM
> To: Joseph D. Wagner; [email protected]
> Subject: GNU server "compromised"? Gimme a break!
>
> http://www.internetnews.com/article.php/2248811
>
> So the excuse is that the GNU/Linux servers holding source code for the
> Free Software Foundation was compromised will be how Stallman and his
> cronies explain the fact that SCO-owned intellectual property got onto
> their servers.
>
> How crazy does it sound when you say this out loud: "A hacker broke into
> our open source servers and slipped proprietary code into the source code
> of GNU/Linux in an attempt to plant evidence to frame us"?
> -
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Err...have you ever used GRSec or SELinux? Both do (in-kernel btw) what you
claim does not exist in GNU/Linux. And SELinux is in 2.6... Do some research
next time.
On Thursday 14 August 2003 07:55 pm, Joseph D. Wagner wrote:
> I just think this goes a long way to say that GNU/Linux security sucks, the
> theory of a thousand eyes isn't true because the eyes aren't looking,
> GNU/Linux security sucks, FSF is administrated by incompetent boobs (notice
> that even their pre-hacked backups could be compromised -- um, "offsite
> backups" anyone?), GNU/Linux security sucks, auditing is non-existent
> because they can't tell who did what (they'd first need ACL's for this),
> GNU/Linux security sucks, backdoors can be in open source code, ... and did
> I mention that GNU/Linux security sucks?
>
> > -----Original Message-----
> > From: Scott McCollum [mailto:[email protected]]
> > Sent: Thursday, August 14, 2003 5:14 PM
> > To: Joseph D. Wagner; [email protected]
> > Subject: GNU server "compromised"? Gimme a break!
> >
> > http://www.internetnews.com/article.php/2248811
> >
> > So the excuse is that the GNU/Linux servers holding source code for the
> > Free Software Foundation was compromised will be how Stallman and his
> > cronies explain the fact that SCO-owned intellectual property got onto
> > their servers.
> >
> > How crazy does it sound when you say this out loud: "A hacker broke into
> > our open source servers and slipped proprietary code into the source code
> > of GNU/Linux in an attempt to plant evidence to frame us"?
> > -
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
- --
Bryan D. Stine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/PCTQ4Cdq/Vbot6MRAtrtAJ4lFIA9Daxb/NeUW/4xJtT53f/4NACgiLVf
fhyqyKwYrU8CcCm5d4qre8A=
=rhKA
-----END PGP SIGNATURE-----
Hiall,
does someone have experience in porting some Kernel to Double-Harvard-Arch?
I don't think Lx was ever ported to such a kind of µP (please correct me!),
all I found on the web were several ports to embedded, but still vNeumann-,
or Single-Harvard µPs.
DH means, that the µprocessor (typically a DSP) has a seperated program
memory, a seperate (X)Data memory and a seperate (Y)Data mem, so it can
fetch two data adresses simultanely in one cycle via two physically
independent mem ports. For DSPs, that's a common behaviour!
So, obviously one (me) will have to integrate two flavours of malloc()
into the Kernel (vmallocX() and vmallocY()). Of course, i could leave this
issue to a specialized (uC)glibc, but i think, it should be the job of the
kernel to keep the oversight on memory issues...;)
Any ideas how to manage that trouble as "frictionless" as can?,
And¡
In article <[email protected]> you wrote:
> DH means, that the ?processor (typically a DSP) has a seperated program
> memory, a seperate (X)Data memory and a seperate (Y)Data mem, so it can
> fetch two data adresses simultanely in one cycle via two physically
> independent mem ports. For DSPs, that's a common behaviour!
Is this an embedded syste which has only the DSP, or is this a DSP add on
card for a PC? In the later case it migh be easier to write an device
driver.
Do you habe GCC support for your intended hardware?
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/