Slashdot Mirror
Crypto and IPSec Merged into 2.5
Corbet writes "Linus has just merged the new crypto API and IPSec implementation into his 2.5 BitKeeper tree. This is the first time that serious cryptographic code has made an appearance in the mainline kernel, and it will hopefully lead to more secure communications for all Linux users in the future."
IPsec has no support for IPv6.. what now?
now theres finally a unix for pc that has ipsec and crypto builtin!!! what i would i do.. whats that? freebsd you say? holyyyyy shit
- AIX is dying.
- AmigaOS is dying.
- BSD is dying.
- BeOS is dying.
- CPM is dying.
- DOS is dying.
- FreeBSD is dying.
- GNU Hurd is dying.
- HP-UX is dying.
- IRIX is dying.
- Inferno is dying.
- Linux is dying.
- LynxOS is dying.
- MINIX is dying.
- MacOS is dying.
- Mach is dying.
- MicroC/OS is dying.
- NachOS is dying.
- NeXT is dying.
- Nemesis is dying.
- NetBSD is dying.
- NetWare is dying.
- OS-400 is dying.
- OS-9 is dying.
- OS/2 is dying.
- Oberon is dying.
- OpenBSD is dying.
- Palm OS is dying.
- Plan 9 is dying.
- pSOS is dying.
- QNX is dying.
- RTEMS is dying.
- SCO is dying.
- Solaris is dying.
- SunOS is dying.
- TRON is dying.
- ThreadX is dying.
- TinyOS is dying.
- Unix is dying.
- VMS is dying.
- VxWorks is dying.
- Windows 2000 is dying.
- Windows 3.11 is dying.
- Windows 95 is dying.
- Windows 98 is dying.
- Windows CE is dying.
- Windows ME is dying.
- Windows NT is dying.
- Windows XP is dying.
The Free On-Line Dictionary of Computing defines an operating system as: "The low-level software which handles the interface to peripheral hardware, schedules tasks, allocates storage, and presents a default interface to the user when no application program is running. The OS may be split into a kernel which is always present and various system programs which use facilities provided by the kernel to perform higher-level house-keeping tasks, often acting as servers in a client-server relationship. Some would include a graphical user interface and window system as part of the OS, others would not."The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.
The comp.os.research FAQ makes the following distinction between micro- and macrokernels:
"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.
For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.
However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.
As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.
Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.
PHP is moving to Linux!
Well, he already looks like the other indefinitely arrested detainees.
France surrenders!