Well, I actually did (sort of). I was following the 4.0-CURRENT branch (i.e., cvsup tag=.) before 5.0-CURRENT existed. Of course, once 5.0 became the head and I recompiled a new kernel, I got loads of nasty surprises. The funny thing was that I didn't notice that the bootup message said 5.0 until a few days later, and I was terribly upset by how unstable the 4.0 branch suddenly had become.
Mike Smith, BSDi, FreeBSD project, hardware, iA64 port
Uh. Is this for real? Is there an IA64 port in the works? I've never heard that this has been mentioned before. Looking at the CVS now, I see that it's got an src/sys/ia64 subdir, but that subdir seems to be rather empty. Does anyone have any info on this?
Uhm, if I remember correctly, actually serving this from a single machine was the impressive part of the record. And, if you look at the number 1.39 TB/day, you see that on average it boils down to 16.9 MB/sec. Taking a few peaks now and then into consideration, I don't see why bus bandwidth would be a problem. As for the 10,000 simultanoues connections, I am not sure how stressfull this is for the OS. You have to remember that long lived FTP connections are generally a lot more easy on the OS than all these annoying short lived HTTP connections.
I must admit that I almost fell into an hysteric laugh when I read this (your link) a few months back, expecially since some of you people (not you though) seem to believe that HURD+Guile would be a good starting point for Tunes.
And of course, from the programmer's point of view, one of the things that really differs between IA-32 and IA-64 is that you have loads of more registers to make use of (128 general, 128 floating point). This alleviates the need to shuffle registers to the stack for almost every single operation you do, lessening the stack/memory usage. I mean, if you look at some compiled x86 code, you get really amazed by how much code that is there just for the purpose of shuffeling registers around.
However, having loads of registers doesn't always make the OS designer very happy. Just think of the amount of memory needed to store the state of a single thread (2KB of registers + some other state). It's an insane amount, especially if you have to do loads of context switches. Fortunately though, the Itanium do contain mechanisms that makes life easier for the OS.
Since other people have talked about the advantages of the Itanium in particular, I thought that I should try to actually answer your question: what is the advantages of 64-bit systems?
Well, for starters, 64-bit systems usually comes with 64-bit data paths (buses). I'm saying usually because one could in theory implement a 8-bit bus that semantically behaved like a 64-bit bus. For instance, Amigas have 32-bit CPUs, but were equipped with a 16-bit bus. Having wider buses helps a great deal for most applications since the memory bandwidth is increased.
Also, 64-bit systems usually comes with a bus address path that is more than 32 bits. For instance, MIPS is 64-bit and is equipped with a bus that accepts 54 address bits (is this correct?). This enables you to put more than 4GB of memory into the machine and actually access the memory in a clean way from you appliction.
One of the most intriguing aspects of 64-bit architectures though, is that your virtual memory addess space is 64 bits. This allow you to implement things like single address space operating systems. You can also have huge files mapped into your address space (imagine having a movie of, say a few hundred gigs, mapped into your application), easing the development of applications tremendously. You could denote a few upper bits of an address to identifying hosts, and implement a large cluster of distributed shared memory. You could denote parts of the address to containing the process id, leaving you with a system where one particular address is unique both over time and among other applications. The list goes on...
As you can see, 64-bit architectures offer some obvious performance advantages. The biggest advantage though, as I see it, is that it opens up the door for some interseting operating system research/design.
Even if this is the case -- does it really matter? I mean, who cares if Linux or Win2k was the first OS that booted on the Itanium. What counts is if the OS is fully functional and stable, and if it becomes stable before the Itanium hits the market.
Taken the complaints many people have that an HTML page can not always be rendered very nicely into WML, I tried to find out search engines that searched exclusively for WML pages. I found at least four different engines. Two of them seem to be more or less bogus (Waply and WapWarp). The best one seems to be FAST Wap Search. Are the any other good WAP search engines out there?
(Sigh, another example of great moderation. I'm really starting to believe that most moderation is done by bots nowdays.)
Why do people spend so much effort in overclocking, when they could overclock the software? If you have the source, you can profile the C code and rewrite the critical 1% in asm, without overheating the cpu.
I guess that the easy answer would be that most people overclock in order to improve the speed of their games; something which people often do not have source code for. Anyhow, I believe that most game developers (at least those who deal with graphic engines or compute intensive algortihms) have spent a good deal of time analyzing and optimizing their inner loops.
That said, after fiddling around with those lovely pentium performance counters, I've found that the code you're optimizing many times tend to behave quite differently depending on the type of CPU, and its speed (stalls at different locations, slightly different cache behaviour, etc.). Understanding exactly why things behave differently is therefore paramount when doing these sort of optimizations. Unfortunealty, in order to understand why things behave differently you will need a thorough understanding of mostly all the components of the CPU. Few people -- if any -- have this understanding.
PS! I don't mind if anyone calls me a Perl Monkey (I proably am one). I also consider myself competent enogh to do the occasional low level programming. I fully have to agree with you on those script kiddies though.:-)
Looks like a neat little device. However, the pictures of the device reveals that the expansion slot (e.g. for CD-rom) is located on the same side as the USB port. This implies that the USB port (e.g. ethernet connection) can not be used in conjunction with the expansion slot. What a shame.
Nah, he's just saying that having 98% in a prog course is not equal to the ability to read cod. I fully have to agree with that. Being a programmer does not help you in these matters. Maybe being a gypsy or something would. I don't know.
I'm inclined to say that I find it strange that you -- for all one knows a talented programmer -- are not able to understand other peoples code. This however, is often the crux of the problem when auditing code; understanding other peoples reasoning behind the code is so very different from writing the code yourself. Most people I have seen being graduated don't know shit about reading other people's code, or doing software maintenance on a large scale or semi large scale project. They are only able to read their own code, and in some cases, they are only able to do so for a period of, say, two weeks. Moreover, these people are often not able to produce very understandable or maintainable code. I've spent several years tutoring/teaching CS courses, and the quality of the code that students produce mostly suck big time. It's scary.
So, are we all damned then? Is open software deemed to be a flop? No, of course not. The reason being that most core people involved in develompemnt/auditing of open source software is pretty good at what they're doing, and they know their specific software (or part of the software) just as thorougly as their own pocket.
So I submit that it is not that nobody is reading the source for programs. Rather, TONS of people are reading it, they just don't know what they are looking at.
Taken that avarage rewiever weighs about 80kg, there will only go about 13 reviewers into a ton. That doesn't sound like to many.:-)
(PS! The arguments presented above were not targeted specifically on you. They were just meant as general ranting.)
Someone with a cd burner and a fast connection could probably do pretty well selling 3.5.
And of course, if that someone realized that he didn't have to download the CD image each time he was going to burn it, a mere CD burner would do the trick.;-)
I wouldn't mind having dual boot become a new definition, where you actually run BeOS, MacOS, *BSD, Linux,and even Winblows at the same time.
Except of course that none of them (except MkLinux) runs on top of Mach though. The day Microsoft creates a Windows running on top of Mach, I'll eat my mousepad.
Now, of course, the problem of running multiple OS personalities on top of a microkernel is one of resource allocation. Deciding on how much the different OS personalities should get of, say memory, is just a minor problem. They probably need to agree upon a protocol for sharing/granting memory to each other. Then there is the problem of device drivers. Who should for instance be be responsible for the disk driver (having multiple disk drivers accessing the same hardware simultaneously simply does not work)? Furthermore, say that Linux is responsible for the disk driver, how can BeOS be allowed to access the disk?
Uhm, come to think of it, this last argument (i.e. device drivers) is not that valid for Mach since it has some in-kernel device drivers. (On the other hand, Mach is not really a modern -kernel, so there you go.) It does however allow user-level device drivers to be implemented, so... Oh well, what do I know. I've never used Mach (except from through Hurd), and much less implemented a device driver. I guess I'll just stop rambling about this and go do something useful.
What I really love about the FreeBSD kernel compilation is that all generated source files, header files, and object files are kept in separate compile directories (one for each kernel configuration). This way you can compile multiple kernels simultaneously without having the different kernel compilations interfere with each other. I haven't compiled a Linux kernel in ages though, so it might be that this is supported nowdays.
It doesn't take to much imagination to picture some makefile (or any other part of the source package for that matter) containing code for replicating itself though.
Folks who download and compile the source would be safe, but folks who download the executable get a nasty surprise.
Is this true? Who on earth would be so insane as to ``validate'' the some 400.000 lines of C code and 700.000 lines of lisp code when installing Emacs. The only way to be sure that the content of the package is well-behaved is to use some sort of signatures/checksums (e.g. like in the BSD ports collections). Using signatures on source packages however, is not different from using signatures on binary distibutions.
Does anyone know if any of the Linux distributions make use of some signature scheme for distributed packages?
I must say; I just love that new regexp feature (i.e. matching balanced tokens). That's what I've been missing for years. I always had to come up with some hacky way of doing it in the end.
And even better. The new regexp feature seems more generic than a simple balanced token matcher. I mean, it could match things like (matching text in bold):
I've never tried this mind you. From the example on the reference page I would guess that this was fairly simple to accomplish though. Oh joy. Try to do that with any other regexp engine.
Have any of you tried to run a browser with cookies turned completely off. There are *many* sites that will not even let you look around.
Pardon me if I'm wrong here, but I suspect that most browsers keep their cookie file in memory once loaded (i.e. they don't care if the cookie is deleted from the cookie file during the browser session).
My point is this: symlink your cookies file to/dev/null. You will be able to use the cookies for you whole browser session, and next time you fire up the browser you will start off with a blank cookies file.
I take it that you are thinking in the lanes of Bochs here, i.e. being able to run non-x86 code on an x86 box. If this is the case, I wouldn't hold my breath waiting for it. IA-64 is way to far off from IA-32. Ever looked at the hardware system architecture guides for the Itanium? I mean, there is a reason why Intel refused to release any simulator to OS developers. They simply said that the simulator was not stable enough, and that once the first prototypes were out, nobody would want the simulators anyway. Keeping personell on maintaining a non-stable simulator would not pay off. (As it is however, few people are able to get their hands on them prototypes. Even developers at places like IBM have a hard time getting just a fraction of the required hardware resources. This is another story though.)
As for plex86, the following question in the information page answers your question:
Will this run on my Mac?
This kind of technology allows you to concurrently run multiple operating systems written for the same processor. In the case of FreeMWare, you will be able to run multiple Intel x86 based operating systems on the same machine. Thus the answer is no. However, the virtualization concepts used by FreeMWare can be extended to other platforms.
Judging from the IA-64 docs however, I don't think this will happen in the forseeable future (I might be a bit short sighted here). First of all comes the fact that you'll have to emulate IA-32 since IA-64 cpus can run in IA-32 mode. Then comes all those nasty addition features of the IA-64. It takes quite and effort just getting to understand the whole architecture fully.
I can see your concernt with mingling GPL'ed code with your BSD licensed program. The configure scripts however (as generated by autoconf) are not GPL'ed. The last time I did an autoconf, the script that was produced contained the following text in its header:
This configure script is free software; the Free Software Foundation gives unlimited permission to copy, distribute and modify it.
I would say that this enabled you to do most anything you could imagine with the script. It is afterall ``compiled'' out of your configure.in files that you miy very well put under the BSD license.
I see, I should have stated myself more clearly. I am not talking of glibc (i.e. libc.a), but of GLib (i.e. libg.a). Take a look at the reference manual to get a feeling of what it provides. As I said before, it is a most useful tool.
I almost coulnd't agree with you more. The part of having Linux stuff compiled unmodified on BSDs is not entirely true though. OK, for smaller applications it is true; I;ll give you that. When going to mid-sized application like Xmms however, one tends to run into quite a few problems. I mean, there are all these things like accessing the cdrom, handling floating point exceptions, and so on. Even for things that are supposed to behave the same on different OS platforms (like the OSS sound API emulation of the FreeBSD PCM driver) there are subtleties that you have to take care of.
./configure && make install` shall set you free.
Nah, make install && make distclean does it for me.:-)
I wouldn't call Linux and BSD mere different distros. And as far as I see it, the main problem with writing portable software is to get it running on different OSes - not to get it running on different hardware platforms (taken that they are supported by the OS that is).
Slashdot Mirror
Well, I actually did (sort of). I was following the 4.0-CURRENT branch (i.e., cvsup tag=.) before 5.0-CURRENT existed. Of course, once 5.0 became the head and I recompiled a new kernel, I got loads of nasty surprises. The funny thing was that I didn't notice that the bootup message said 5.0 until a few days later, and I was terribly upset by how unstable the 4.0 branch suddenly had become.
Uh. Is this for real? Is there an IA64 port in the works? I've never heard that this has been mentioned before. Looking at the CVS now, I see that it's got an src/sys/ia64 subdir, but that subdir seems to be rather empty. Does anyone have any info on this?
Uhm, if I remember correctly, actually serving this from a single machine was the impressive part of the record. And, if you look at the number 1.39 TB/day, you see that on average it boils down to 16.9 MB/sec. Taking a few peaks now and then into consideration, I don't see why bus bandwidth would be a problem. As for the 10,000 simultanoues connections, I am not sure how stressfull this is for the OS. You have to remember that long lived FTP connections are generally a lot more easy on the OS than all these annoying short lived HTTP connections.
I must admit that I almost fell into an hysteric laugh when I read this (your link) a few months back, expecially since some of you people (not you though) seem to believe that HURD+Guile would be a good starting point for Tunes.
However, having loads of registers doesn't always make the OS designer very happy. Just think of the amount of memory needed to store the state of a single thread (2KB of registers + some other state). It's an insane amount, especially if you have to do loads of context switches. Fortunately though, the Itanium do contain mechanisms that makes life easier for the OS.
Well, for starters, 64-bit systems usually comes with 64-bit data paths (buses). I'm saying usually because one could in theory implement a 8-bit bus that semantically behaved like a 64-bit bus. For instance, Amigas have 32-bit CPUs, but were equipped with a 16-bit bus. Having wider buses helps a great deal for most applications since the memory bandwidth is increased.
Also, 64-bit systems usually comes with a bus address path that is more than 32 bits. For instance, MIPS is 64-bit and is equipped with a bus that accepts 54 address bits (is this correct?). This enables you to put more than 4GB of memory into the machine and actually access the memory in a clean way from you appliction.
One of the most intriguing aspects of 64-bit architectures though, is that your virtual memory addess space is 64 bits. This allow you to implement things like single address space operating systems. You can also have huge files mapped into your address space (imagine having a movie of, say a few hundred gigs, mapped into your application), easing the development of applications tremendously. You could denote a few upper bits of an address to identifying hosts, and implement a large cluster of distributed shared memory. You could denote parts of the address to containing the process id, leaving you with a system where one particular address is unique both over time and among other applications. The list goes on...
As you can see, 64-bit architectures offer some obvious performance advantages. The biggest advantage though, as I see it, is that it opens up the door for some interseting operating system research/design.
Even if this is the case -- does it really matter? I mean, who cares if Linux or Win2k was the first OS that booted on the Itanium. What counts is if the OS is fully functional and stable, and if it becomes stable before the Itanium hits the market.
Taken the complaints many people have that an HTML page can not always be rendered very nicely into WML, I tried to find out search engines that searched exclusively for WML pages. I found at least four different engines. Two of them seem to be more or less bogus (Waply and WapWarp). The best one seems to be FAST Wap Search. Are the any other good WAP search engines out there?
Why do people spend so much effort in overclocking, when they could overclock the software? If you have the source, you can profile the C code and rewrite the critical 1% in asm, without overheating the cpu.
I guess that the easy answer would be that most people overclock in order to improve the speed of their games; something which people often do not have source code for. Anyhow, I believe that most game developers (at least those who deal with graphic engines or compute intensive algortihms) have spent a good deal of time analyzing and optimizing their inner loops.
That said, after fiddling around with those lovely pentium performance counters, I've found that the code you're optimizing many times tend to behave quite differently depending on the type of CPU, and its speed (stalls at different locations, slightly different cache behaviour, etc.). Understanding exactly why things behave differently is therefore paramount when doing these sort of optimizations. Unfortunealty, in order to understand why things behave differently you will need a thorough understanding of mostly all the components of the CPU. Few people -- if any -- have this understanding.
PS! I don't mind if anyone calls me a Perl Monkey (I proably am one). I also consider myself competent enogh to do the occasional low level programming. I fully have to agree with you on those script kiddies though. :-)
Of course, all the magic would have to be programmed in Perl. ;-)
Looks like a neat little device. However, the pictures of the device reveals that the expansion slot (e.g. for CD-rom) is located on the same side as the USB port. This implies that the USB port (e.g. ethernet connection) can not be used in conjunction with the expansion slot. What a shame.
Nah, he's just saying that having 98% in a prog course is not equal to the ability to read cod. I fully have to agree with that. Being a programmer does not help you in these matters. Maybe being a gypsy or something would. I don't know.
So, are we all damned then? Is open software deemed to be a flop? No, of course not. The reason being that most core people involved in develompemnt/auditing of open source software is pretty good at what they're doing, and they know their specific software (or part of the software) just as thorougly as their own pocket.
So I submit that it is not that nobody is reading the source for programs. Rather, TONS of people are reading it, they just don't know what they are looking at.
Taken that avarage rewiever weighs about 80kg, there will only go about 13 reviewers into a ton. That doesn't sound like to many. :-)
(PS! The arguments presented above were not targeted specifically on you. They were just meant as general ranting.)
And of course, if that someone realized that he didn't have to download the CD image each time he was going to burn it, a mere CD burner would do the trick. ;-)
Except of course that none of them (except MkLinux) runs on top of Mach though. The day Microsoft creates a Windows running on top of Mach, I'll eat my mousepad.
Now, of course, the problem of running multiple OS personalities on top of a microkernel is one of resource allocation. Deciding on how much the different OS personalities should get of, say memory, is just a minor problem. They probably need to agree upon a protocol for sharing/granting memory to each other. Then there is the problem of device drivers. Who should for instance be be responsible for the disk driver (having multiple disk drivers accessing the same hardware simultaneously simply does not work)? Furthermore, say that Linux is responsible for the disk driver, how can BeOS be allowed to access the disk?
Uhm, come to think of it, this last argument (i.e. device drivers) is not that valid for Mach since it has some in-kernel device drivers. (On the other hand, Mach is not really a modern -kernel, so there you go.) It does however allow user-level device drivers to be implemented, so... Oh well, what do I know. I've never used Mach (except from through Hurd), and much less implemented a device driver. I guess I'll just stop rambling about this and go do something useful.
What I really love about the FreeBSD kernel compilation is that all generated source files, header files, and object files are kept in separate compile directories (one for each kernel configuration). This way you can compile multiple kernels simultaneously without having the different kernel compilations interfere with each other. I haven't compiled a Linux kernel in ages though, so it might be that this is supported nowdays.
It doesn't take to much imagination to picture some makefile (or any other part of the source package for that matter) containing code for replicating itself though.
Is this true? Who on earth would be so insane as to ``validate'' the some 400.000 lines of C code and 700.000 lines of lisp code when installing Emacs. The only way to be sure that the content of the package is well-behaved is to use some sort of signatures/checksums (e.g. like in the BSD ports collections). Using signatures on source packages however, is not different from using signatures on binary distibutions.
Does anyone know if any of the Linux distributions make use of some signature scheme for distributed packages?
And even better. The new regexp feature seems more generic than a simple balanced token matcher. I mean, it could match things like (matching text in bold):
I've never tried this mind you. From the example on the reference page I would guess that this was fairly simple to accomplish though. Oh joy. Try to do that with any other regexp engine.Pardon me if I'm wrong here, but I suspect that most browsers keep their cookie file in memory once loaded (i.e. they don't care if the cookie is deleted from the cookie file during the browser session).
My point is this: symlink your cookies file to /dev/null. You will be able to use the cookies for you whole browser session, and next time you fire up the browser you will start off with a blank cookies file.
As for plex86, the following question in the information page answers your question:
Will this run on my Mac?
Judging from the IA-64 docs however, I don't think this will happen in the forseeable future (I might be a bit short sighted here). First of all comes the fact that you'll have to emulate IA-32 since IA-64 cpus can run in IA-32 mode. Then comes all those nasty addition features of the IA-64. It takes quite and effort just getting to understand the whole architecture fully.I see, I should have stated myself more clearly. I am not talking of glibc (i.e. libc.a), but of GLib (i.e. libg.a). Take a look at the reference manual to get a feeling of what it provides. As I said before, it is a most useful tool.
Nah, make install && make distclean does it for me. :-)
I wouldn't call Linux and BSD mere different distros. And as far as I see it, the main problem with writing portable software is to get it running on different OSes - not to get it running on different hardware platforms (taken that they are supported by the OS that is).