No, they are just under the impression that they have a clue. Any semi-competent international-terrorist/drug-lord/whatever will realize they can get their strong encryption abroad. The only group of people that these restrictions effect are those that follow the law... I don't understand why they can't see how utterly pointless these restrictions are!
Do the majority of US citizens actually support the regulation of strong encryption? Does the gov't really represent the people?
Re: Cool. Now I know why Debian is buggy!
on
XFree86 News
·
· Score: 1
Umm, that is why they are putting it into unstable (potato) and not stable (slink).
Now, if they had a buggy/unstable version of X in potato when potato became stable, that would be a different story.
I think even if you have 128MB+ RAM, you still want swap. If you have at least some swap, inactive processes can be swapped out in favor of cache when there is heavy disk activity.
Perhaps the reason it takes longer to spawn a process has to do with the ABI "emulation". (There is another post on how this works.)
From what I understand, rather than having fixed syscall #s, freebsd (and probably open/netbsd) load an array of syscalls, which differs between the various supported ABIs.
Has anyone benchmarked this sort of thing? It would stand to reason that the extra overhead associated with supporting different ABIs would make spawning a process (or at least loading an executable) more expensive.
(Please correct me if I am wrong... I really am curious about this.)
I think when people say that linux is not "unix" they are referring to the fact that it was written from scratch, rather than derived from BSD (ie BSD 4.4, not xBSD) or AT&T code.
Unless you are sentimental, I don't think this is a good/valid reason for choosing one over the other.
(I suppose the fact that at least some device drivers for linux and xBSD where writen by the same person blurs this a little...)
I'm sorry, but this idea scares me. Why don't we just all adopt 95/NT!
I think it is good to have some diversity... because the source code to xBSD and linux is available, the best ideas from each may find there way into the other.
For the most part, user-land software is quite portable between linux/xBSD/, so I don't think the splintered efforts are quite the problem that you make them out to be. After all, when it comes to the free OSs, I think it is the user-land software where they are lacking the most. (Not to say that this isn't rapidly changing.)
Linux -NFS server: not so good (is there any work being done on this?)
I agree... this was a big motivation for moving one of our fileservers at work to freebsd. And I am pushing for freebsd on the new servers. The kernel level nfs server for linux has better performance, but there seem to be some compatibility issues. -SMB client: good -SMP: good (could be better) -Portability: good -Ease of configuration: good (I love System V and kernel modules)
I agree... I prefer sysv, but that could be because I cut my teeth on linux and solaris... I must say that rc.conf is growing on me:) -RAID: never tried -TCP/IP: good (I add this just because the older Linux kernel didn't do TCP/IP near as well as FreeBSD)
FreeBSD -NFS server: good -SMB client: not so good (I don't think kernel level support exists - ie smbmount. does it?)
hmm, never tried the client side... the bsd box at work is running like a champ as a smb server, tho. -SMP: not so good
In my experiance (I have a dual celeron at home) freebsd is as good, or perhaps better than linux when it comes to SMP. -Portability: not so good (use NetBSD - whole other topic) -Ease of configuration: Ok (but I really wish they would move to System V - is it possible to make a disto that is System V?) -RAID: good (I love vinum) -TCP/IP: good
I think that the BIOS setting can control write access only when the BIOS is used to access the drive... so unless your running DOS on your server, I don't think this will do any good.
At work I have to dual boot, because we do all our documentation in M$ word. We do our documentation in M$ word because that is what everyone else uses, and we need to be able to exchange documents with partners/customers. We don't want to use word... in fact word is a pretty crappy word processor... but we *have* to use it because it is an industry standard. I call that a monopoly!
Also, we have tools that are only available on windows {NT/95}. They are only available for windows because that is what most people use. Most people use windows because M$ does it's best to prevent anyone from using anything else... it's only been recently that you could buy a computer from a big name manufacturor with any OS other than windows installed. I call that a monopoly!
Sure, M$ has made computers a bit easier to use for the beginner, but if M$ wasn't here, someone else would have done it, and probably would have done a better job. I really can't think of a single aspect of the computer industry that would be worse if M$ didn't exist!
What I am really trying to figure out is how to trap writes/reads to certain addresses without having to interpret the machine instructions... the best hack I have thought of is to trap SIGSEGV, and have your signal handler try to figure out what was going on.
For example you can mark pages of memory as a not being readable (PROT_NONE flag for the mmap). This will cause a SIGSEGV if the program tries to read/write that address.
Another idea I just thought of as I was writing this post... you could use a kernel module to create a/proc file, then have your VM mmap that file to use as it's memory. Then the module could deal with simulating memory space. (This is assuming you can prevent the mmap file from being cached.) This would be even better if you could bind a user-space program to a file. (I vaguely remember reading that GNU hurd has the ability to do this.)
I would hazard the guess that there are lots of places where a whole block of IP address are assigned when there really only need to be a couple IP addresses assigned.
For example, FooBar Corp. grabs a class B so each of their computers can have an IP address. However, they only have a small handful of external servers and gateways. What they really should have done is gotten individual IP addresses from their ISP and used IP masquerading for all the internal computers. That way, computers that are behind their firewall aren't using "real" IP addresses.
Re:We need a new TOPIC (actually two topics)
on
Linux 2.3.0
·
· Score: 1
One for stable kernel releases and one for unstable releases. Any maybe the unstable release announcements could be filtered out by default?
Re:Warning! Rocky shores ahead!
on
Linux 2.3.0
·
· Score: 2
Re:Is USB supported? - maybe sorta?
on
Linux 2.2.8
·
· Score: 1
The include for drivers/usb/Config.in is commented out in arch/i386/config.in. Uncomment it, and USB will show up in menuconfig. It isn't even in the config.in for other platforms.
I still haven't gotten it running, tho, so YMMV. At boot time, it doesn't detect the USB keyboard. If you send SIGUSR1 to the uhci-control thread to dump some debugging info, it does detect the keyboard... but alas it still doesn't work.
I had big problems with the userland NFS server under linux, which went away with the kernel level server.
The server was/is a P133 with IDE disks on a 10baseT network. (Yes, I know... pretty weak server...) When writing ~50 MB from two clients (in this case, Sun ultra 1's) the userland NFS server would hang. I am sure the problem would be worse on a 100baseT network.
Switching to knfsd fixed the problem. AFAIK, the NFS server on solaris and the other big commercial flavors of unix are kernel level servers.
I just noticed that the private IP address ranges have showed up in DNS with the name "read-rfc1918-for-details.iana.net". (RFC1918 is the one that specifies the ranges of class A, B, and C private IP numbers.)
I assume this is a mistake? It seems to have happened within the last day or two, I think. I only noticed because my IP-masq box stopped letting me telnet/ftp in! (I have pretty strict hosts.deny & hosts.allow... when I was trying to log in, rpc looked up the IP address of the machine I was logging in from, 192.168.1.10, and got a DNS reply for a subnet that wasn't allowed, which prevented me from telnet'ing in.)
On the 32 bit processors that I experiance with linux on (ie intel and ppc), the 32 bit address space is divided in two, with 2 gigs for physical RAM, and 2 gigs for memory mapped hardware.
I would assume that 64 bit processors have a similar arrangement... ie 2^63 for RAM and 2^63 for hardware addresses.
It looks like The Linux Store is "a service of" CPU Micromart. I don't know if that means their service will be as bad as CPU Micromart, or not. Just though I should warn people, though.
(I have ordered stuff from CPU Micromart, and I eventually got it, but I don't know that I would recommend them.)
Well, why don't we just have ourselves a dictatorship, eh? That would bypass pesky old congress. I trust a one person gov't even less that congress!
... and there has never been a gov't that has crushed the weak?
I think the government's job should be to protect people's rights, and not take them away.
No, they are just under the impression that they have a clue. Any semi-competent international-terrorist/drug-lord/whatever will realize they can get their strong encryption abroad. The only group of people that these restrictions effect are those that follow the law... I don't understand why they can't see how utterly pointless these restrictions are!
Do the majority of US citizens actually support the regulation of strong encryption? Does the gov't really represent the people?
Umm, that is why they are putting it into unstable (potato) and not stable (slink).
Now, if they had a buggy/unstable version of X in potato when potato became stable, that would be a different story.
I think even if you have 128MB+ RAM, you still want swap. If you have at least some swap, inactive processes can be swapped out in favor of cache when there is heavy disk activity.
Perhaps the reason it takes longer to spawn a process has to do with the ABI "emulation". (There is another post on how this works.)
From what I understand, rather than having fixed syscall #s, freebsd (and probably open/netbsd) load an array of syscalls, which differs between the various supported ABIs.
Has anyone benchmarked this sort of thing? It would stand to reason that the extra overhead associated with supporting different ABIs would make spawning a process (or at least loading an executable) more expensive.
(Please correct me if I am wrong... I really am curious about this.)
I think when people say that linux is not "unix" they are referring to the fact that it was written from scratch, rather than derived from BSD (ie BSD 4.4, not xBSD) or AT&T code.
Unless you are sentimental, I don't think this is a good/valid reason for choosing one over the other.
(I suppose the fact that at least some device drivers for linux and xBSD where writen by the same person blurs this a little...)
I'm sorry, but this idea scares me. Why don't we just all adopt 95/NT!
I think it is good to have some diversity... because the source code to xBSD and linux is available, the best ideas from each may find there way into the other.
For the most part, user-land software is quite portable between linux/xBSD/, so I don't think the splintered efforts are quite the problem that you make them out to be. After all, when it comes to the free OSs, I think it is the user-land software where they are lacking the most. (Not to say that this isn't rapidly changing.)
I should have mentioned that I was using -current (ie v4.0)... I don't know too much about SMP on the 3.2 branch.
Also, two processors isn't much of a stress test as far as SMP scalability... perhaps as you add more processors linux will have more of an advantage.
Linux
:)
-NFS server: not so good (is there any work being done on this?)
I agree... this was a big motivation for moving one of our fileservers at work to freebsd. And I am pushing for freebsd on the new servers. The kernel level nfs server for linux has better performance, but there seem to be some compatibility issues.
-SMB client: good
-SMP: good (could be better)
-Portability: good
-Ease of configuration: good (I love System V and kernel modules)
I agree... I prefer sysv, but that could be because I cut my teeth on linux and solaris... I must say that rc.conf is growing on me
-RAID: never tried
-TCP/IP: good (I add this just because the older Linux kernel didn't do TCP/IP near as well as FreeBSD)
FreeBSD
-NFS server: good
-SMB client: not so good (I don't think kernel level support exists - ie smbmount. does it?)
hmm, never tried the client side... the bsd box at work is running like a champ as a smb server, tho.
-SMP: not so good
In my experiance (I have a dual celeron at home) freebsd is as good, or perhaps better than linux when it comes to SMP.
-Portability: not so good (use NetBSD - whole other topic)
-Ease of configuration: Ok (but I really wish they would move to System V - is it possible to make a disto that is System V?)
-RAID: good (I love vinum)
-TCP/IP: good
I think that the BIOS setting can control write access only when the BIOS is used to access the drive... so unless your running DOS on your server, I don't think this will do any good.
What do you me M$ doesn't have a monopoly!!!
At work I have to dual boot, because we do all our documentation in M$ word. We do our documentation in M$ word because that is what everyone else uses, and we need to be able to exchange documents with partners/customers. We don't want to use word... in fact word is a pretty crappy word processor... but we *have* to use it because it is an industry standard. I call that a monopoly!
Also, we have tools that are only available on windows {NT/95}. They are only available for windows because that is what most people use. Most people use windows because M$ does it's best to prevent anyone from using anything else... it's only been recently that you could buy a computer from a big name manufacturor with any OS other than windows installed. I call that a monopoly!
Sure, M$ has made computers a bit easier to use for the beginner, but if M$ wasn't here, someone else would have done it, and probably would have done a better job. I really can't think of a single aspect of the computer industry that would be worse if M$ didn't exist!
1) linux, general
2) linux kernel, stable
3) linux kernel, unstable
This way folks can have the flexibility to filter out some/all/none of the linux related posts.
What I am really trying to figure out is how to trap writes/reads to certain addresses without having to interpret the machine instructions... the best hack I have thought of is to trap SIGSEGV, and have your signal handler try to figure out what was going on.
/proc file, then have your VM mmap that file to use as it's memory. Then the module could deal with simulating memory space. (This is assuming you can prevent the mmap file from being cached.) This would be even better if you could bind a user-space program to a file. (I vaguely remember reading that GNU hurd has the ability to do this.)
For example you can mark pages of memory as a not being readable (PROT_NONE flag for the mmap). This will cause a SIGSEGV if the program tries to read/write that address.
Another idea I just thought of as I was writing this post... you could use a kernel module to create a
Doesn't apache run on winnt? Why not bench apache on NT vs. apache on linux? After all, are we benching different web servers, or the OS?
I would hazard the guess that there are lots of places where a whole block of IP address are assigned when there really only need to be a couple IP addresses assigned.
For example, FooBar Corp. grabs a class B so each of their computers can have an IP address. However, they only have a small handful of external servers and gateways. What they really should have done is gotten individual IP addresses from their ISP and used IP masquerading for all the internal computers. That way, computers that are behind their firewall aren't using "real" IP addresses.
One for stable kernel releases and one for unstable releases. Any maybe the unstable release announcements could be filtered out by default?
The include for drivers/usb/Config.in is commented out in arch/i386/config.in. Uncomment it, and USB will show up in menuconfig. It isn't even in the config.in for other platforms.
I still haven't gotten it running, tho, so YMMV. At boot time, it doesn't detect the USB keyboard. If you send SIGUSR1 to the uhci-control thread to dump some debugging info, it does detect the keyboard... but alas it still doesn't work.
-- Rob
I had big problems with the userland NFS server under linux, which went away with the kernel level server.
The server was/is a P133 with IDE disks on a 10baseT network. (Yes, I know... pretty weak server...) When writing ~50 MB from two clients (in this case, Sun ultra 1's) the userland NFS server would hang. I am sure the problem would be worse on a 100baseT network.
Switching to knfsd fixed the problem. AFAIK, the NFS server on solaris and the other big commercial flavors of unix are kernel level servers.
Hmm, maybe we should start CC'ing the emails to the advertisors... maybe some of 'em will pull the ads, so the site makes less $$$...
I just noticed that the private IP address ranges have showed up in DNS with the name "read-rfc1918-for-details.iana.net". (RFC1918 is the one that specifies the ranges of class A, B, and C private IP numbers.)
I assume this is a mistake? It seems to have happened within the last day or two, I think. I only noticed because my IP-masq box stopped letting me telnet/ftp in! (I have pretty strict hosts.deny & hosts.allow... when I was trying to log in, rpc looked up the IP address of the machine I was logging in from, 192.168.1.10, and got a DNS reply for a subnet that wasn't allowed, which prevented me from telnet'ing in.)
20k loc is too low! I've done that in six months!
On the 32 bit processors that I experiance with linux on (ie intel and ppc), the 32 bit address space is divided in two, with 2 gigs for physical RAM, and 2 gigs for memory mapped hardware.
I would assume that 64 bit processors have a similar arrangement... ie 2^63 for RAM and 2^63 for hardware addresses.
It looks like The Linux Store is "a service of" CPU Micromart. I don't know if that means their service will be as bad as CPU Micromart, or not. Just though I should warn people, though.
(I have ordered stuff from CPU Micromart, and I eventually got it, but I don't know that I would recommend them.)