3) There are 3 hats, but two colours. This means that out of 12 possible combinations, there are 2 that are "all hats
same colour" - so 1/6th of the time. Thus, if you see 2 hats of the same colour, the probability that your hat is the
same color is 1/6 - which in turn implies that guessing that your hat is a different colour will be correct 5/6th of the
time.
Not really, there are 2^3 = 8 possible combinations. Two in which everyone has the same color, meaning that there's a 3/4 chance that everyone does not have the same color (and thus is able to win the game). Another way to think of it: the first player is given a color (say C). The two other players each has 1/2 chance of getting the color C, i.e., 1/4 chance of both getting the color C -- or 3/4 that not eveyone has the same color.
No? Why not? Listen, replacing X isn't going to be easy. And unless you're going to do it, shut up and stop whining.
Instead, THANK the people who have *given* you a Free implementation of the X Windowing System. Got it?
Good.
I always get a bit put off by opinions like this. Just give the guy a break. He merely pointed out that he believed X to be suboptimal for certain tasks. Throwing stuff like ``shut up, be thankful for what you got, we don't need any second opinions on what we create'' isn't really going to help much. The only thing such comments are good for is to draw people away from using open source alternatives altogether. Why is it that many open source coders treats users in much the same way that sysadmins do (i.e., they loath them because users always tend to make their job a bit more tedious).
Yes, it's pretty disgusting ain't it. One would believe that more ``educated'' people would have a more mature view on Open Source. I guess I'll just go home and die, knowing that the world surely is doomed...
Yes, this is what I had to do. I didn't like it though....Although I did manage to get it working by using the ports version, they only have old stuff (Apache 1.3.14, modPHP 4.0.3pl1).
As the other reply pointer out -- if you want to stay updated on the ports collection, you should use CVSup or the like. Both Apache 1.3.17 and mod_php 4.0.4pl1 have been in the ports collection since February 12 and February 5 respectfully. You just have to have some patience. When a new port is released (and in particular if the port is sort of big and/or complex) it takes a bit of time for the port maintainer to ensure that the port compiles and runs on all supported versions of the OS (remember that they should work on both the 3.x, 4.x, and 5.x branches). There might also be times when a FreeBSD porter does not include a new version into the port collection for a reason (i.e., it contain bugs). Usually you can send a mail to the port maintainer listed in the Makefile and ask him/her if they have any plans to upgrade a particular port.
I've only been using FreeBSD for 2 days, but I get the impression that the BSD crowd is
unfriendly and snotty compared to the Linux crowd - although I haven't talked to any other BSD users, I have read on the
net that the BSD crowd can be snotty/rude.
Er, well, what can I say? You seem to have managed to give an answer your own problems in the second part of the sentence. Quite an amazing feat;-).
Re:Oracle/Java on FreeBSD
on
Is BSD Dying?
·
· Score: 1
I wouldn't call the Linux support in FreeBSD emulation (although I admittedly tend to use that word lacking a better one). FreeBSD simply implements the Linux ABI. In most cases, the implementation is simply a one-to-one mapping between the Linux system call and the FreeBSD system call. In some cases some of the arguments would have to be tweaked or swapped around. In other cases one would have to implement some functionality which is not readily available in the FreeBSd kernel. In any case, I don't see how the FreeBSD implementation of the Linux ABI to differ that much from the Linux implementation of it. And frankly, I don't think Oracle would refuse anyone to run their servers under FreeBSD. They might not give support for it, true, but they would probably not prohibit it.
Do you own an X series laptop? If not, why are you complaining already?
Complaining because I might very probably be using one some day and I would like to be able to run FreeBSD on it. We tend to almost exclusively use ThinkPads here at work and when next upgrade of my notebook comes into question, an X series would be a prime candidate.
Well, you're not entirely wrong either.;-) Package upgrading in FreeBSD can admittedly be sort of a hassle if you want everything to be done entirely correct (e.g., dependencies). Point is that the -f swicth to pkg_delete will indeed remove the package. Disadvantage is that the dependency information in the pkg-database will be slightly inconsistent. This isn't that much of an issue really, it only (possibly) causes later deletes to spout out some error messages (which can be ignored).
There have been reoccuring discussions among ports-people of how to deal with this, but to my knowledge nobody has produced any good solution to it yet. Of course, the Open Packages project looks promising -- uniting package maintaining between BSDs (including Darwin) and incorporating the various enhancements into one single base packaging system. It might even provide a good solution to the upgrading hassle.
Just out of curiosity, what the fsck are you doing with more than 7 disklabel partitions in one single FreeBSD slice? Just having a recap from disklabel(8):
Finally newfs the filesystem partitions you created in the label. A typical disklabel partitioning scheme would be to have an ``a'' partition of approximately 128MB to hold the root filesystem, a ``b'' partition for swap, a ``d'' partition for/var (usually 128MB), an ``e'' partition for/var/tmp (usually 128MB), an ``f'' partition for/usr (usually around 2G), and finally a ``g'' partition for/home (usually all remaining space). Your mileage may vary.
I would have thought that this would be more than enough for most uses. If there was any reason to have more partitions, one would expect that the user would be able to create another slice containing those. (For non-BSD users, a slice in BSD speak is a normal fdisk like partition. This has the advantage that you don't have to use multiple slices/fdisk-partitions for a single BSD installation.)
So, the question again: may I dare to ask why anyone would want more than 7 partitions in a single slice?
As far as I can remember, the partition ID problem also applied to the X series. Now, I looked up the latest BIOS update that I could find on the X20 (January 30), but it seems that this update does not address the partition ID problem. Does anyone know if IBM has fixed this in a prior update, or wheter they simply ``forgot'' to fix things on the X20 too?
C++ (any any other OO Language) does add some overhead to a program and in the case of an application that can be affordable, but I would rather have a OS written in C or even better Assembler, because the OS should "just" be the OS nothing else.
Not entirely true. You just have to be a bit careful about the features that you use. Using virtual functions, for example, might not be desireable. Creating operators like the complex multiplication as inline functions on the other hand, adds no overhead. It only makes code more readable. Just think about the simple example of comparing two structs. You could create a macro or inline functions that take two structs as arguments, or you could create an inline == operator for the structs.
When I studied/worked at University of Tromsø, we developed a course where the students were to create a full fledged operating system (TeachOS) from scratch (on x86 hardware). The projects that the sutends had to do were as follows:
Bootup and printf. Bootup the kernel. Use a printf facility to put charecters to the screen.
Simple batch scheduling. A number of threads should be run. The scheduler simply runs all threads till completion.
Non-preemptive scheduling. Threads yield control of processor voluntarily. A keyboard thread reads characters from the keyboard. A shell-thread reads characters from a keyboard buffer and writes them to screen.
Preemptive scheduling and system calls. The keyboard-driver is now interrupt driven. A timer interrupt enforces scheduling. Two shell-threads make use of int-instructions to generate system calls.
Multithreaded and preemptive kernel. The kernel is made preemptive. Multiple threads are allowed to execute inside the kernel simultaneously. Spinlocks are used for synchornization.
Inter Process Communication (IPC). Send and receive system calls are implemented. The receive call is blocking. As such, the kernel must now support some sort of thread-suspend/thread-resume.
Virtual memory and user-level. Taks now run in virtual memory protected from each other. A task may contain multiple threads. It is also necessarry to make a clear distinction between user-level and kernel-level.
Demand paging. Students are given a hard-disk driver that are allowed to access a Linux swap partition. When there is no more physical memory, the kernel swaps out pages to disk using some replacement policy. Bss, data, and text sections are mapped on demand.
Princeton University also made use of some of this, but I'm not sure what modifications they did. Some effort has also later been put into improving the course, and the OS has changed its name to LearnOS.
The ChacmOS that you mentioned, was actually developed by some students while taking a course in System Design and Implementation, at Karlsruhe University. It is not just a class project, but a full fledged course that we have just started developing here. The idea, as the name suggests, is that students shall learn how to design larger systems (in particular operating systems) and implement them.
The 64 bits are not only useful for addressing +4GB of physical memory. It also opens up the possibility for using virtual memory more agressivly than one can do in conventional 32 bit systems. Here's a short list of the top of my head that large address spaces is useful for:
Implementing distributed shared memory (as in sharing humongous amounts of memory).
Using a separate memory region for each created process (i.e., implementing the PID in the MSB of the address), ensuring that the address of all created objects are unique in both space and time.
Mapping the whole contents of Slashdot into your virtual address space.;-)
The list goes on. For the purpose of fueling intersting research, more true 64 bit architectures are certainly welcomed.
As other people said -- the P4 was not really recalled. However, for the sake of argument, let's say that it was recalled. Point is that the target for the P4 and the Itanium are probably as far appart as you can come. As the article says, the Itanium is mostly targeted at people who wants to get their feet into the IA-64 before the McKinley hits the market. The P4 is targeted for the mass market (high end PC/workstation/server). The latter can not tolerate any irregularities of the processor, the former can.
Works (sort of). As far as I know, it still does not contain any IA-64 specific optimizations though (e.g., making use of register rotation). I think some independent groups have been working on IA-64 issues, but they have not yet merged these additions into the main development tree. Also, the release is just one big bundle with GCC, Binutils, GDB, and everything thrown into one big source tree. And it seems that nothing has been updated on that front since mid May.
One might also use the Pro64 compiler from SGI. This compiler does implement IA-64 specific optimizations and it even generates assembler code which is easily readable. The compiler does not come with an assembler or a linker, however, so you'll have to rely on GCC to do that part of the job for you.
It doesn't matter if the device driver has its own virtual address space. The hardware is still writing to physical memory, and thus the hardware can still corrupt unrelated memory.
True. This does not apply to all servers though. Some servers operate purely on virtual memory, providing some sort of service for the user (e.g., parts of a network stack). Such a faulty server will usually not break the whole system. Also, having things run in a separate address space does help making the system more robust. What I mean here is that it is more likely that a bug in a server is merely a stray pointer that makes the server chrash, than a bogus write to a hardware register.
You don't address my main point: if the Hurd is so much easier to write and extend, why is it still incomplete and unusable fter more than a dozen years?
I think this has more to do with development resources than with the original OS architecture. I'm sure that the Hurd would have gotten way further along if it had the same amount of development resources (developers) as Linux does.
And as for usuability, I believe that you can indeed make use of the Hurd. (I have not used it extensively myself though. Just played around with it for a few hours to see how things worked.)
Question: Why would you choose to transport 5 people from spot A to spot B with 5 bikes instead of one car? What would you do when you were to transport 6 people?
This is not a good analogy. Neither does it answer your question. However, to put it short. Running MkLinux on top of Mach is not that much different from having a monolithic system -- it is just a monolithic system running on top of a microkernel. Having this input, you should be able to deduce yourself (from reading the referred article or other posts in this thread) why Hurd is not a duplication of the MkLinux effort.
I don't think the Hurd (or any other OS) for that matter will be a brain drain for the Linux kernel. Thing is that most (kernel) programmers stick to a system which they are familiar with. New programmers will find some project that they want to work on, and they will maybe come to master that project to great extent (and stick to it).
Also, being a kernel developer is not necessarily any harder than developing for a user-level project. This is a myth. In fact, it might in many cases be easier to be a kernel developer becasue you do not have to deal with different operating system APIs. In other words, they key issue is complexity. That is, there are relatively few Linux kernel developers because the complexity of the kernel is too high (and not well enough docuemented) to overcome for most people. So, if the kernel itself is less complex, more people would be able to make contributions. I think this was the main reason that I chose to ditch Linux in favour of BSD years ago -- I just got too fed up with the ugly undocumented hacks inside the Linux kernel.
(Note, I'm not saying that BSD is completely free of hacks, but I do find the code easier to understand. In addition, you tend to get manual pages for in-kernel features. The size of my man9 section currently counts 233.)
I'm yet to see a definition of the term microkernel which makes it include Linux. If you do use such a definition for yourself, please do not expect other people to agree with you.
(I don't really know why I care to followup on trolls. I guess I just don't want to do any real work today.)
Anyway, it's kind of funny that a ``Linux site'' like this cares to include a whole section just for such esoteric software as BSD. And as for the posts that usually goes into more detail of why OpenBSD claims to be the most secure, they usually end up as being viewed as Linux-bashing, and subsequently modded as flamebait or troll.
I'm just wondering what fdisk like utilities say about hibernation partitions. Are they claiming that they are BSD partitions? That would certainly be quite confisuing for Windows users -- ``Say, I just got my new Laptop from IBM the other day, and they had pre-installed some BSD something in one of the partitions.''
Slashdot Mirror
Not really, there are 2^3 = 8 possible combinations. Two in which everyone has the same color, meaning that there's a 3/4 chance that everyone does not have the same color (and thus is able to win the game). Another way to think of it: the first player is given a color (say C). The two other players each has 1/2 chance of getting the color C, i.e., 1/4 chance of both getting the color C -- or 3/4 that not eveyone has the same color.
I always get a bit put off by opinions like this. Just give the guy a break. He merely pointed out that he believed X to be suboptimal for certain tasks. Throwing stuff like ``shut up, be thankful for what you got, we don't need any second opinions on what we create'' isn't really going to help much. The only thing such comments are good for is to draw people away from using open source alternatives altogether. Why is it that many open source coders treats users in much the same way that sysadmins do (i.e., they loath them because users always tend to make their job a bit more tedious).
Yes, it's pretty disgusting ain't it. One would believe that more ``educated'' people would have a more mature view on Open Source. I guess I'll just go home and die, knowing that the world surely is doomed...
Of course, if you do fancy to use Google you could always use the Google BSD section.
As the other reply pointer out -- if you want to stay updated on the ports collection, you should use CVSup or the like. Both Apache 1.3.17 and mod_php 4.0.4pl1 have been in the ports collection since February 12 and February 5 respectfully. You just have to have some patience. When a new port is released (and in particular if the port is sort of big and/or complex) it takes a bit of time for the port maintainer to ensure that the port compiles and runs on all supported versions of the OS (remember that they should work on both the 3.x, 4.x, and 5.x branches). There might also be times when a FreeBSD porter does not include a new version into the port collection for a reason (i.e., it contain bugs). Usually you can send a mail to the port maintainer listed in the Makefile and ask him/her if they have any plans to upgrade a particular port.
I've only been using FreeBSD for 2 days, but I get the impression that the BSD crowd is unfriendly and snotty compared to the Linux crowd - although I haven't talked to any other BSD users, I have read on the net that the BSD crowd can be snotty/rude.
Er, well, what can I say? You seem to have managed to give an answer your own problems in the second part of the sentence. Quite an amazing feat ;-).
I wouldn't call the Linux support in FreeBSD emulation (although I admittedly tend to use that word lacking a better one). FreeBSD simply implements the Linux ABI. In most cases, the implementation is simply a one-to-one mapping between the Linux system call and the FreeBSD system call. In some cases some of the arguments would have to be tweaked or swapped around. In other cases one would have to implement some functionality which is not readily available in the FreeBSd kernel. In any case, I don't see how the FreeBSD implementation of the Linux ABI to differ that much from the Linux implementation of it. And frankly, I don't think Oracle would refuse anyone to run their servers under FreeBSD. They might not give support for it, true, but they would probably not prohibit it.
Complaining because I might very probably be using one some day and I would like to be able to run FreeBSD on it. We tend to almost exclusively use ThinkPads here at work and when next upgrade of my notebook comes into question, an X series would be a prime candidate.
Which was a pretty bad example since XMMS runs perfectly fine without any changes. ;-) If it does not, please tell me.
There have been reoccuring discussions among ports-people of how to deal with this, but to my knowledge nobody has produced any good solution to it yet. Of course, the Open Packages project looks promising -- uniting package maintaining between BSDs (including Darwin) and incorporating the various enhancements into one single base packaging system. It might even provide a good solution to the upgrading hassle.
So, the question again: may I dare to ask why anyone would want more than 7 partitions in a single slice?
As far as I can remember, the partition ID problem also applied to the X series. Now, I looked up the latest BIOS update that I could find on the X20 (January 30), but it seems that this update does not address the partition ID problem. Does anyone know if IBM has fixed this in a prior update, or wheter they simply ``forgot'' to fix things on the X20 too?
Not entirely true. You just have to be a bit careful about the features that you use. Using virtual functions, for example, might not be desireable. Creating operators like the complex multiplication as inline functions on the other hand, adds no overhead. It only makes code more readable. Just think about the simple example of comparing two structs. You could create a macro or inline functions that take two structs as arguments, or you could create an inline == operator for the structs.
- Bootup and printf. Bootup the kernel. Use a printf facility to put charecters to the screen.
- Simple batch scheduling. A number of threads should be run. The scheduler simply runs all threads till completion.
- Non-preemptive scheduling. Threads yield control of processor voluntarily. A keyboard thread reads characters from the keyboard. A shell-thread reads characters from a keyboard buffer and writes them to screen.
- Preemptive scheduling and system calls. The keyboard-driver is now interrupt driven. A timer interrupt enforces scheduling. Two shell-threads make use of int-instructions to generate system calls.
- Multithreaded and preemptive kernel. The kernel is made preemptive. Multiple threads are allowed to execute inside the kernel simultaneously. Spinlocks are used for synchornization.
- Inter Process Communication (IPC). Send and receive system calls are implemented. The receive call is blocking. As such, the kernel must now support some sort of thread-suspend/thread-resume.
- Virtual memory and user-level. Taks now run in virtual memory protected from each other. A task may contain multiple threads. It is also necessarry to make a clear distinction between user-level and kernel-level.
- Demand paging. Students are given a hard-disk driver that are allowed to access a Linux swap partition. When there is no more physical memory, the kernel swaps out pages to disk using some replacement policy. Bss, data, and text sections are mapped on demand.
Princeton University also made use of some of this, but I'm not sure what modifications they did. Some effort has also later been put into improving the course, and the OS has changed its name to LearnOS.The ChacmOS that you mentioned, was actually developed by some students while taking a course in System Design and Implementation, at Karlsruhe University. It is not just a class project, but a full fledged course that we have just started developing here. The idea, as the name suggests, is that students shall learn how to design larger systems (in particular operating systems) and implement them.
- Single address space operating systems (SASOS).
- Mapping huge files into your application space.
- Implementing distributed shared memory (as in sharing humongous amounts of memory).
- Using a separate memory region for each created process (i.e., implementing the PID in the MSB of the address), ensuring that the address of all created objects are unique in both space and time.
- Mapping the whole contents of Slashdot into your virtual address space.
;-)
The list goes on. For the purpose of fueling intersting research, more true 64 bit architectures are certainly welcomed.As other people said -- the P4 was not really recalled. However, for the sake of argument, let's say that it was recalled. Point is that the target for the P4 and the Itanium are probably as far appart as you can come. As the article says, the Itanium is mostly targeted at people who wants to get their feet into the IA-64 before the McKinley hits the market. The P4 is targeted for the mass market (high end PC/workstation/server). The latter can not tolerate any irregularities of the processor, the former can.
One might also use the Pro64 compiler from SGI. This compiler does implement IA-64 specific optimizations and it even generates assembler code which is easily readable. The compiler does not come with an assembler or a linker, however, so you'll have to rely on GCC to do that part of the job for you.
I think most people here are very aware of the differences between a server as in web server, and a server as in a Hurd server.
True. This does not apply to all servers though. Some servers operate purely on virtual memory, providing some sort of service for the user (e.g., parts of a network stack). Such a faulty server will usually not break the whole system. Also, having things run in a separate address space does help making the system more robust. What I mean here is that it is more likely that a bug in a server is merely a stray pointer that makes the server chrash, than a bogus write to a hardware register.
You don't address my main point: if the Hurd is so much easier to write and extend, why is it still incomplete and unusable fter more than a dozen years?
I think this has more to do with development resources than with the original OS architecture. I'm sure that the Hurd would have gotten way further along if it had the same amount of development resources (developers) as Linux does.
And as for usuability, I believe that you can indeed make use of the Hurd. (I have not used it extensively myself though. Just played around with it for a few hours to see how things worked.)
This is not a good analogy. Neither does it answer your question. However, to put it short. Running MkLinux on top of Mach is not that much different from having a monolithic system -- it is just a monolithic system running on top of a microkernel. Having this input, you should be able to deduce yourself (from reading the referred article or other posts in this thread) why Hurd is not a duplication of the MkLinux effort.
Also, being a kernel developer is not necessarily any harder than developing for a user-level project. This is a myth. In fact, it might in many cases be easier to be a kernel developer becasue you do not have to deal with different operating system APIs. In other words, they key issue is complexity. That is, there are relatively few Linux kernel developers because the complexity of the kernel is too high (and not well enough docuemented) to overcome for most people. So, if the kernel itself is less complex, more people would be able to make contributions. I think this was the main reason that I chose to ditch Linux in favour of BSD years ago -- I just got too fed up with the ugly undocumented hacks inside the Linux kernel.
(Note, I'm not saying that BSD is completely free of hacks, but I do find the code easier to understand. In addition, you tend to get manual pages for in-kernel features. The size of my man9 section currently counts 233.)
I'm yet to see a definition of the term microkernel which makes it include Linux. If you do use such a definition for yourself, please do not expect other people to agree with you.
Anyway, it's kind of funny that a ``Linux site'' like this cares to include a whole section just for such esoteric software as BSD. And as for the posts that usually goes into more detail of why OpenBSD claims to be the most secure, they usually end up as being viewed as Linux-bashing, and subsequently modded as flamebait or troll.
I'm just wondering what fdisk like utilities say about hibernation partitions. Are they claiming that they are BSD partitions? That would certainly be quite confisuing for Windows users -- ``Say, I just got my new Laptop from IBM the other day, and they had pre-installed some BSD something in one of the partitions.''