The test series still have problems, notably with the VM and with I/O throughput.
For most people the test series perform _very_ poor compared to the 2.2 series when it comes to disk thoughput. 2.4-test is as slow as 1/5 of 2.2 for some.
But, 2.4-test is ready for testing. Definitely. Get the kernel, build it, run it, stress it. The developers need all the input they can get. If you have the time, then follow LKML from the archives (from kernelnotes.org or elsewhere), and respond with a benchmark/feedback every time a developer posts a patch.
The 2.4 series has a large number of optimizations over the 2.2 series, so most of the kernel should run a lot better than 2.2. But if your disk throughput is low and your kernel swaps unnecessarily, those other optimizations get you nowhere. AFAIK the only performance-related problems in 2.4-test is I/O and VM related. Once these are fixed, 2.4 is going to be the leanest kernel of them all.
Now I see why VC++ is about the crappiest C++ compiler on the MS OS market. Everyone's busy doing other languages, or, perhaps more likely, every competent compiler writer left microsoft a few years back so now they have to make up a language simple enough for them to write a compiler for it.
If you defend VC++ then you don't know C++. Trust me.
A few years back GCC was a very poor C++ compiler, it actually only understood a small subset, and I'm sure VC++ was superior at that time. Then the standard was finished, and someone fixed GCC big time. Today I can take samples from Bjarne's book, compile them on GCC, and collect ``internal compiler error''s from VC++. Or random parser errors. I've ``fixed'' software by inserting function prototypes between class declarations, redefining ``protected'' to ``public'' and the likes, on windows.
Best of all, Microsoft gives no feedback to normal users that turn in bug reports, they give no dates on service releases/upgrades, nothing. If you use C++ you're pretty hosed with the MS solution. Now it seems that we're going to be _really_ hosed, now that microsoft has a new language we should all favour.
If you think of what Java did to sun, imagine what this new language will do to the already poor (nah, missing) support for C++ on MS platforms.
I'll make sure to hire someone to make GCC run well for us on NT. It's time to bail.
Today banner ads are usually a GIF served from some specific site, the link to the GIF is positioned at almost the same place on all sites with banner ads. This simple scheme opens up for the business of ``serving banner ads''. I think that this business is in danger, but not on-line advertising in itself.
Banner ads could be served from the site itself. And they could be made to fit better into the layout and philosophy behind that site. This would bring two things: Banner ads would be less intrusive, and, they would be impossible to block. Both the advertiser and the consumer wins here. (Uh, beware, I see the win-win scenario emerging here)
Companies that today make a living of serving (and accounting hits for) banner ads, will have to find a new living. But the new model should open up for that just fine. There will still be a need for the advertiser to have some figure over the effectiveness of the ad, now that there's no longer to usual third-party involved.
There's still a third party though; the consumer. Most browsers can supply the advertiser with referrer URLs, which would give the advertiser a way of assessing the effectiveness of an ad on some specific site. The advertisers would probably like ways to verify the number of actual exposures of their ad as well. This is where the old ad-serving companies come in. If they figure out a way to act as this third party that can account and verify the number of exposures, they may not be completely out of business after all.
Isn't it wonderful seeing this marketplace mature:)
My impressions is, that this whole deal with splitting up Microsoft, is going to makke microsoft better and stronger in the long run.
Today, their API is a horrible mess of inconcistent calls to inconsistent subsystems, where someone with real knowledge about what's happening in the deeper layers of the OS might have a chance of actually implementing something usable. But for the rest of us, it's black magic.
If Microsoft is forced to open up for more of their specs, eventually forced (my market) to implement and design a usable API, that will not only benefit the 2. Microsoft (the applications department) but also the rest of us.
My guess is, that in two years from now, Microsoft will either have an API that is sufficently similar to POSIX, or they will be in the same position on the desktop as Netware find themselve on the server market today.
Ok, Microsoft API designers (and their managers) aren't the smartes people on earth, obviously (to anyone who've looked at Win32 at least). But they may not be _that_ stupid after all. Win2K has mountponts, maybe the next Win3K5 (or whatever) will have a select() call that works on pipes (generally), sockets, and file descriptors. Maybe they will have a CreateProcess() call that takes less than 10 arguments, it could even be a fork(). Maybe, just maybe, they will learn.
If this happens, we could have a WindowsXXXX platform which would actually be of real use to people who need more than one computer in a network. This could position Windows among the other '70s technology platforms that are in use today, *BSD, Linux, etc. This would be a giant breakthrough for the platform from the '80s that chose to never learn from history otherwise.
Cheers, to whatever the future brings. I personally doubt we'll see the boneheads suddenly starting to learn, but then again, you never know.
Yes I have used an IDE. I used Borland/Turbo C in the old days, and IBM VisualAge for C++ later on. Then I found GNU/Linux.
As part of my job I had to port a large program to NT, so I decided to give VisualStudio a go, after all, I like IDEs very much (I do prefer the X+sawmill+Emacs+make+bash+... IDE, but the others were nice at the time too). I was fairly surprised that they actually had regexp search in, but the joy ended the second I needed to pipe input from one search into another, or just search all files matching a specific pattern... There are no pipes in the GUI unfortunately.
I agree that you don't want to do repetitive typing yourself if it can be avoided. If you could click a button (or preferably, as you already have your hands on the keyboard, just press a specific key) to perform some operation, that is as a starting poing a ``good thing''. This is actually what Emacs tries to do, and that's why you use C-s and C-r for searching, and "C-c C-v i" (longer sequence for less frequently required function) for inserting new files in version control. I don't agree that Emacs is entirely nice here, I just haven't found a better editor for code yet (yes, I use vi for config files and kernel code, but besides that it's emacs all the way).
However (!) If I did find a better editor, it would plug right into my existing framework of window manager, bash, grep, gazillions of other tools. You can't hot-plug the editor in VS.
Anyway, I did really try, believe me, I'm an open minded person, but Visual Studio is in my oppinion a *very* poor substutitute for a *the*real* IDE, for someone who knows various IDEs generally and *the*real* IDE specifically.
I don't know about sticky breakpoints, I rarely debug code (that way). I'd be surprised if GUD didn't supply such a feature (GUD is actually a little fun because while being the Grand Unified Debugger, in Danish it is also the word for God, so, I found God when searching for a debugger;)
The point about repetitive work I think needs another angle of view. Yes, we want to avoid it, and *no* you definitely do not want to type the same stuff over and over again in a shell.
Now, to rename the define F1OO to BAR1, F200 to BAR2 in all.c,.h and.f files, I run: find . -name '*.[chf]' | xargs perl -pie 's/F(\d)OO/BAR$1/'
AND THAT IS IT ! If your IDE doesn't have a button that says ``replace text matching some pattern with another pattern, in all files matching some pattern'', then *you* will have to do your repetitive work clicking buttons whil I have moved on to the next problem a long while ago.
Sure, you need to grasp regular expressions. But if you want to get real work done in any environment (now that even VS is catching on), you might as well do that anyway. And then you need to grasp pipes. Well, start by thinking of it as, say, a pipe.
Not meaning to be sarchastical (if I could only spell that), but I think most of the arguments in this discussion are based on people seeing the problem from some very narrow viewpoint. I may well be doing the same, but for now I'm convinced that I'm not, and looking forward to being proved wrong.
...when we already have the ultimate one at hand: X + some window manager + some editor + make, shells, and tons of utilities.
I feel that people can't see the forest because all the trees are in the way.
With Glade (or equivalents for Qt or VDK or whatever) for GUI design, Emacs/Vi/Joe/..., the make utility, and the incredible number of small utilities (egrep, find, perl -pie, etc.) in any combination you like combined with the power of the shell, you have an absolutely fantastic well integrated development environment that can not only suit most needs, but also be _made_ to suit unforseen needs.
The traditional IDEs are mere subsets of the *real IDE*, and they are good for beginners, no doubt. It's easy to tell someone that to compile press F9, and if you want to do regular expression substition on all files containing the word "SOMETHING", well, you can do it by hand.
For the rest of us, we can set up emacs to call make when we press F9, and we _can_ actually automate arbitrarily complex search or replace commands.
The power of shells and editors all in windows (so you can have multiple shells and editors on-screen simultaneously), where shells can run arbitrary combinations of utilities should not be underestimated.
Instead of re-editing and re-compiling you program to only show specific debug output, you stick an |egrep 'pattern' behind it when you run it. Nice and easy. I could go on forever with that:)
Still, better to have people developing new APIs than having them sell crack to children and what not. I would prefer if people could focus on improving the fantastic IDE we already _have_ though... There should be plenty of opportunity to come up with new small utilities and improvements to the window managers, to the build tools, to the editors, and to things we haven't even thought of yet.
I know you couldn't call it a Beowulf if you chose otherwise, but there's got to be more to it than that (I guess). What other OS'es did you consider, and why did you pick GNU/Linux ?
The only way you can ``contribute'' to your GPL'ed software, is to make the changes under the GPL too. You employer will simply have to accept that any modifications you do while at work, will be licensed under the GPL.
Of course, your employer will most likely hold the copyright on those changes, but the changes will be under GPL.
You can then merge the changes into your GPL software, for which you hold the original copyright, stating that your company now owns some of the GPL'ed code in there. That is, if you approve of the changes of course;)
This is really a wonderful example of how well the GPL works, even though it's fairly restrictive, it solves these issues simply and efficiently. It's perfectly normal for a GPL program to be owned by a lot of people, and that's perfectly fine as long as all the contributers accept that the code they own will be licensed under GPL as well.
In fact, the more people who own code in a GPL program, the harder it will be to actually change the license, as all owners must agree to the change.
Your company will probably be happy to hear that there is no problem in you working on the software, and that they get to keep the copyright on anything you write in company time. Of course, they must accept that their code is GPL'ed, but that's one small camel them must swallow, and seen in the light that they got to use an existing code base for no charge at all, it shouldn't be too hard.
Your real problem is when the company wants a change that you would not approve of wearing your non-company hat. I guess we can't help you with that:)
The Samba team doesn't protect their own confidential trade sectrets very well, and surely they could use this spec if they protected the implementation equally well. Microsoft knows that of course. But hey, they're not just giving away competitive advantages all of the sudden. It's a PR stunt for sure, but it's not good enough to be just that. There _must_ be something important which is not in the spec, or which is different in the spec. What could it be ? I haven't seen the spec myself and I don't know Kerberos stuff, but somehow we're going to find out when Samba implements the spec and some sort of hell breaks lose. My best guess would be that it is related to security - call me detective;) Could there be some blatant backdoor inherent in an implementation following the spec ? Let's hear what people who know Kerberos and the spec say...
...and that's why english is and will be the language of the internet.
English will change of course, with new words meaning new things.
For many years to come, the people building the net will be technicians of some kind. They will be working with programming languages, markup languages, and hardware. I have yet to see a real-world ``computer-language'' (programming or mark-up) that isn't based on english.
I'm not native english myself, but I tend to write source code comments and program output in english anyway. So anyone using or digging into programs I've written, will be using english too. I see everyone else doing the same thing.
Sure, the technicians are not the ones necessarily deciding the language of the program input/output in an application, but I bet that as soon as you look under the hood of 90% of the non-english programs out there, you'll see comments in english still. As long as more than a few people have to work with code like that, english will be the common language of the many.
Even if you decide to not use english, you still will: open(OUTF, "min_fil") or die "Kunne ikke åbne min_fil";
Sure, some company tried to translate the macro language of their international products into using words from the languages of each of the translations. I have yet to meet someone who found that anything but catastrophic. Macro packages for the english version wouldn't run on the german version and vice versa. Even worse, you couldn't share experiences across borders, or read foreign language books about the macro language.
Anything that constrains the benefit of communication between people to within national borders, is doomed. Be it a macro language, or a nationalized internet.
That's what the vector computers do, such as the older Crays or Fujitsu ones. They don't have this wuzzy cache stuff, they just have a few GB of equally fast memory, and then a several hundred instruction deep pipeline.
It's great for matrix multiplications, but it sucks for problems that won't fit into an extremely deep pipeline (most discrete algorithms, eg. 90% of the stuff 90% of people use)
If you have high latency on your memory without a deep pipeline to make up for it (in order to prefetch loooong ahead of time) you'll suffer. And if you run the software most people do who don't do weather forecasts or fusion weaponry, you'll even suffer if you had that pipeline (which you don't). If RDRAM has high latency, it won't make the desktop. Not even marketing will make that happen.
Others have already answered the question with reference to POSIX, but I just thought I'd thow in my two Euro as well...
Recently having ported software between Linux, FreeBSD and NT, I have developed my own idea of what a ``UNIX'' is. It's simplicity most of all. Everything is a file, and most calls that work on file descriptors work on _all_ file descriptors. You can make a select() call on a file, a pipe, and a socket. This is impossible on NT, because files are HANDLEs, sockets are SOCKETs, HANDLEs from anonymous pipes cannot be used for select() like calls (only named pipes there). Why this diversity in the API ?
Running a daemon simply requires you to start up the executable with an "&" if it doesn't support forking to background by itself. I have a routine that does this on UNIX as well as on NT. The UNIX code is perhaps 5-10 lines, and the NT code is roughly 150. On NT you must specifically talk to the service control manager, ask it to ask your program to ask it to ask the program to do all kinds of strange things. Horrible, and inflexible to the extreme.
The system calls on UNIX take a minimum necessary number of arguments, and perform some action fairly much as you would expect it to. An average system call on UNIX probably has, say, 3-4 arguments. I haven't counted the average on NT, but I'd guess it's 6-7 arguments there. This is not because NT is more advanced, but because IMO the design of Win32 is flawed.
As an example, to start up a program on UNIX, you'll write something like (dumbed down): if(!fork()) exec("my_program", arguments, environment) Two system calls that perform a very clear and simple task each, taking 0 and 3 arguments.
The similar code on NT is something along the lines of a call to CreateProcess() which takes 10 (ten!) arguments. These arguments are: program name, command line and environment as on UNIX. Besides, you'll have to pass arguments such as current directory, process security attributes, thread security attributes, filehandle inheritance flag, creation flags, etc. etc. My favorite is that you have to pass an argument specifying the Window Size (!!) of your new process... I nearly pissed my pants when I saw that.
UNIX system calls are fairly consistent. Usually they will return either a 0 pointer, or the integer -1, if the call fails (depending on whether the call returns a pointer or an integer). On NT the calls return either INVALID_PROCESS_HANDLE, INVALID_FILE_HANDLE, INVALID_SOCKET, FALSE, 0, -1, or whatever the failure-return-code-of-the-day was when some call was last rewritten. Error codes can be retrieved from errno on UNIX, while on NT they come from GetLastError() usually (with some exceptions I've happily forgotten about), unless of course it was a socket call that failed, in which case the errorcode can be retrieved from WSAGetLastError(). Sigh.
The point I'm trying to make here is, that to me UNIX stands for a _fairly_ consistent and well designed API. Win32 is neither well designed nor consistent, and porting command line utilities to NT is not going to make it UNIX, not by a long shot.
The GUI wasn't new technology either, neither was pens or a 32-bit OS.
In the public awareness, microsoft already has a gaming console, the x-box, and in 2001 they have been on the market for more than a year. This is what counts. It's lame but it counts, and it's called marketing, like it or not.
By the time the x-box eventually hits the streets (by that time it will have a new name though, because the x-box will get bad press sometime before, because of better specs (or whatever) from the established console companies) people will remember that Microsoft has actually been in the console business for a long time, regardless of the fact that the ``y-box'' is the first thing to actually hit the streets.
Hmm... Now that you're saying it, I actually remember seing the _getspecific call in pthreads a few days back.
My best guess is that it's an implementation that was unsuited for what the thread was all about: multiple threads protecting their hardware graphics contexts using thread private storage. I'm pretty sure that if the pthreads implementation was sufficient, there wouldn't have been such a thread on LKML:)
Forking a whole new process on Linux is faster than spawning a thread on NT - Check your Linux Journal back-issues for numbers.
The idea is to fork two processes and let them share *some* memory. This should do the same as forking one process, then an additional thread with extra private memory - remembering to keep some of the original memory private for the original thread too.
clone(CLONE_VM) will spawn a new thread in the same address space as the calling thread (the original ``process''). It's the way to create a new thread on Linux. Actually AFAIR fork() uses clone() without CLONE_VM to do a ``real'' fork.
All threads making up a ``process'' share the same memory. Thus you don't have something called thread-private storage. However, separate processes (having one or more threads each) may share memory - thus you have a number of threads sharing some memory while keeping some private. Instead of deciding on privatizing, you decide on sharing. You can perfectly well end up with the same end result, and an uncluttered kernel too.
Well I don't remember the whole thread. But I think the conclusion was that thread private storage (or whatever we choose to call it) was not needed when we had DRI (with proper locking) in the kernel. As for threads and context switches in general, context switches are _fast_ under linux. And if you won't be needing the private storage anyway, they're even uncalled for. It doesn't matter that they improve speed on less well designed architectures, if we have the better design.
There was a mention of IRIX which provides thread-private storage. People who had worked on the IRIX kernel clearly stated that Linux should _not_ go there. It's a horrible thing to do to a UNIX kernel, and much better interfaces can be made instead to make the need for thread private storage vanish.
It was great to finally see someone from a fairly closed-source commercial company (even from a guy who in other companies would have pointy hair) state that OSS is not about price, it's about the O and the S before the S.
I work for a company developing closed-source commercial software, for Linux, BSD, NT, and whatever else people want. I (we actually) work on Linux and BSD, *then* port to NT. Why ? Development is _so_ much easier when you have the sources for your platform and tools handy.
Besides, having filed bug reports for both GCC and MS VC++, I can also say that in my experience the community support is not just superior, it's a whole other dimension of willing and useful support.
It's not just the open source alone that matters, it's also the fantastic people behind it. It doesn't matter what you pay for Linux systems (or BSD for that matter), no kind of money could ever buy me this kind of support on a closed source platform. The fact that I don't pay much for Linux is just a nice side effect.
I get *sick* of papers always referring to OSS as ``gratis software'', not Free, not Open. Even though in denmark we have different words for gratis and Free. But hey, they're the people who refer to RMS as a criminal because they've heard he's a hacker...
Linux has threads as the sole ``execution primitive'' or whatever you'd like to call it. Threads can either be alone in their memory space (then we call them processes), or they can be several sharing the memory space (we call them threads). For historical reasons the thread identifier is called the process ID, or pid, but don't let that fool you.
Now with that said, consider the difference between two processes (two single threads in each their memory space) shaing a chunk of memory (shared memory has been available "always" in Linux and UN*X), and two threads (two threads in a single memory space) having private storage...
Tell me the difference... No, wait, there's none (!)
This was discussed on LKML, and the above is my recap of the conclusion. People focus so much on technology instead of what the technology is intended to do, that they fail to see that thread private storage is meaningless when you have processes and shared memory.
To quote Linus' ending statement:
I'll take portability, sanity and clean design before some "my dick is bigger than your dick" direct rendering argument any day. - Linus Torvalds (commenting on IRIX, GL and thread-private storage)
I was pretty darn close to starting a reimplementation for X myself a few years ago. I actually mailed Microprose to ask them for the source (no shit!), for some reason I never even got a reply:*( (well, trying was fun too)
The two first versions of the game were great, the third one sort of ruined it IMO. If only I had a year or two I didn't know what to do with, I'd be firing up gcc&Mesa and get that baby done with.
Actually doing a reimplementation would probably be the easiest, and by far the most fun. Think about XCom in 1600x1200, MesaGL, original plot, MP3 background music, drooool....
I'd love to ask "Any takers?" but I just _can't_ go into this myself now.
1) Software on a PII is slower than software on an i960 or i486 or M68something ? That's a new one... 2) The Linux kernel has excellent caching techniques. Besides, it uses your main memory for caching, so you get the benefit of having a dynamically sized cache, adapting to your needs at any given time 3) A HW controller doesn't magically make all your disks hot swappable. Often people are happy just their system keeps running until some time where they can conveniently take it down and replace failed disks. I'm happy with that:) 4) No serious sysadmin is going to use anything but csh and a Sparc5. But for the rest of us, the better performing, more flexible, and cheeper solution is definitely something that shouldn't just be ignored. 5) You can build nice RAID-5 sets with IDE, just buy a few extra IDE controllers, use only one disk per bus (to keep good performance), and you're off.
The point of RAID without hotswap is saving you a night of reinstalling and restoring backups. You will have to take the system down to replace the disk, but you can do this at a convenient time. That's worth a lot to many of us. And remember this is often at the price of one extra disk.
Think about it for a second: The overhead imposed on your CPU when doing software RAID is something like going thru one extra layer in the FS-> VFS-> block device-> (RAID)-> buffer/cache-> device chain. It's something like 30 extra lines of C code (give and take). This is just _not_ going to make your CPUs peg to 100%. Something else must have been doing this to you, I don't know what, but I've _never_ heard anyone report this. For the record my own box with 4 4.5G IBM SCSI disks do 30+ MB/s sustained transfers on RAID-0. For me the speed limit is here because of crappy memory bandwith on the aging PPro system.
SW RAID should work with IDE, SCSI, and any combination you please. Your experience sounds pretty strange.
If you didn't patch the 2.2.14 kernel and didn't use an -ac patch, then you've been running the old RAID code. This is inferior to the 0.90 code available as patches, but RAID-0 performance should be comparable. My guess is something else in your setup caused this CPU hogging. If it's just misconfiguration of the RAID, it's pretty interesting as I've seen noone else hitting the problem you describe.
Old habits die hard I guess. I stopped counting the number of times people in disbelief have seen Software RAID wipe the floor with their HW solution, performance wise. Drop by the linux-raid list (archives eventually) and see for yourself some day.
Even if we agree that it's not for production (I don't agree, but let's assume so for a second) you still didn't want to use your hand-patched ATA/66 card for production either now, did you ?
If you want to swap systems, SW RAID is just as fine. Swap the disks and the other system will boot on them as well. Wether they're attached to a SCSI controller with RAID capability or not makes no difference. The other system will see the volumes too, the configuration doesn't change magically when moved from one system to the other...
IDE lacks hotswap capability, that's why it's often considered a bad idea. But compare it to a production server _without_ RAID, and suddenly it's one hell of a lot better. You can take the machine down some time convenient, and you won't be reinstalling and restoring backups all night.
Go with Linux Software RAID instead, and save even more money. The 0.90 code (which works very well) is available as patches to the 2.2 series, and is currently being integrated into the 2.3 series.
This will support RAID-linear, -0, -1, -4 and -5. It will work with your ATA cards as well as with your SCSI ones. The IDE layer in Linux is stable enough to survive any disk failure I've ever seen, so stability is as good as it gets.
Besides, Software RAID solutions are usually somewhere between faster and _much_ faster than HW ones. Back in the old days it was a gain to do RAID management in software on an auxillary processor (``hardware'' RAID), but these days your average 400MHz PII won't even notice the extra workload (it's neglible to running ``top'' etc.).
Check out the HOWTO at http://ostenfeld.dk/~jakob/Software-RAID.HOWTO. It's also in the process of getting into the LDP, so we'll be nicely set up for when 2.4 hits the street.
NT has had symlinks for a long time. No hardlinks though. This seems more like `automatic' hardlinks to me...
Anyway, they added mountpoints to Win2K too. Finally the end of drive letters...
And they're skipping WINS in favour of DNS (with their own extensions though).
They're getting there. In a few decades NT might actually become a nice UNIX. Now if I could just see the kernel code for the syscalls I think behave funny, like in any decent kernel;)
Linear and RAID-0 should compile and work (I've only tried RAID-0 myself, on 2.3.47). There was a little hazzle with autodetection/boot support, but other than that, it worked.
The other RAID levels should be on their way.
Oh, and the HOWTO should be on it's way into the LDP now.
Slashdot Mirror
The test series still have problems, notably with the VM and with I/O throughput.
For most people the test series perform _very_ poor compared to the 2.2 series when it comes to disk thoughput. 2.4-test is as slow as 1/5 of 2.2 for some.
But, 2.4-test is ready for testing. Definitely. Get the kernel, build it, run it, stress it. The developers need all the input they can get. If you have the time, then follow LKML from the archives (from kernelnotes.org or elsewhere), and respond with a benchmark/feedback every time a developer posts a patch.
The 2.4 series has a large number of optimizations over the 2.2 series, so most of the kernel should run a lot better than 2.2. But if your disk throughput is low and your kernel swaps unnecessarily, those other optimizations get you nowhere. AFAIK the only performance-related problems in 2.4-test is I/O and VM related. Once these are fixed, 2.4 is going to be the leanest kernel of them all.
Now I see why VC++ is about the crappiest C++ compiler on the MS OS market. Everyone's busy doing other languages, or, perhaps more likely, every competent compiler writer left microsoft a few years back so now they have to make up a language simple enough for them to write a compiler for it.
If you defend VC++ then you don't know C++. Trust me.
A few years back GCC was a very poor C++ compiler, it actually only understood a small subset, and I'm sure VC++ was superior at that time. Then the standard was finished, and someone fixed GCC big time. Today I can take samples from Bjarne's book, compile them on GCC, and collect ``internal compiler error''s from VC++. Or random parser errors. I've ``fixed'' software by inserting function prototypes between class declarations, redefining ``protected'' to ``public'' and the likes, on windows.
Best of all, Microsoft gives no feedback to normal users that turn in bug reports, they give no dates on service releases/upgrades, nothing. If you use C++ you're pretty hosed with the MS solution. Now it seems that we're going to be _really_ hosed, now that microsoft has a new language we should all favour.
If you think of what Java did to sun, imagine what this new language will do to the already poor (nah, missing) support for C++ on MS platforms.
I'll make sure to hire someone to make GCC run well for us on NT. It's time to bail.
Today banner ads are usually a GIF served from some specific site, the link to the GIF is positioned at almost the same place on all sites with banner ads. This simple scheme opens up for the business of ``serving banner ads''. I think that this business is in danger, but not on-line advertising in itself.
:)
Banner ads could be served from the site itself. And they could be made to fit better into the layout and philosophy behind that site. This would bring two things: Banner ads would be less intrusive, and, they would be impossible to block. Both the advertiser and the consumer wins here. (Uh, beware, I see the win-win scenario emerging here)
Companies that today make a living of serving (and accounting hits for) banner ads, will have to find a new living. But the new model should open up for that just fine. There will still be a need for the advertiser to have some figure over the effectiveness of the ad, now that there's no longer to usual third-party involved.
There's still a third party though; the consumer. Most browsers can supply the advertiser with referrer URLs, which would give the advertiser a way of assessing the effectiveness of an ad on some specific site. The advertisers would probably like ways to verify the number of actual exposures of their ad as well. This is where the old ad-serving companies come in. If they figure out a way to act as this third party that can account and verify the number of exposures, they may not be completely out of business after all.
Isn't it wonderful seeing this marketplace mature
My impressions is, that this whole deal with splitting up Microsoft, is going to makke microsoft better and stronger in the long run.
Today, their API is a horrible mess of inconcistent calls to inconsistent subsystems, where someone with real knowledge about what's happening in the deeper layers of the OS might have a chance of actually implementing something usable. But for the rest of us, it's black magic.
If Microsoft is forced to open up for more of their specs, eventually forced (my market) to implement and design a usable API, that will not only benefit the 2. Microsoft (the applications department) but also the rest of us.
My guess is, that in two years from now, Microsoft will either have an API that is sufficently similar to POSIX, or they will be in the same position on the desktop as Netware find themselve on the server market today.
Ok, Microsoft API designers (and their managers) aren't the smartes people on earth, obviously (to anyone who've looked at Win32 at least). But they may not be _that_ stupid after all. Win2K has mountponts, maybe the next Win3K5 (or whatever) will have a select() call that works on pipes (generally), sockets, and file descriptors. Maybe they will have a CreateProcess() call that takes less than 10 arguments, it could even be a fork(). Maybe, just maybe, they will learn.
If this happens, we could have a WindowsXXXX platform which would actually be of real use to people who need more than one computer in a network. This could position Windows among the other '70s technology platforms that are in use today, *BSD, Linux, etc. This would be a giant breakthrough for the platform from the '80s that chose to never learn from history otherwise.
Cheers, to whatever the future brings. I personally doubt we'll see the boneheads suddenly starting to learn, but then again, you never know.
Yes I have used an IDE. I used Borland/Turbo C in the old days, and IBM VisualAge for C++ later on. Then I found GNU/Linux.
;)
.c, .h and .f files, I run:
As part of my job I had to port a large program to NT, so I decided to give VisualStudio a go, after all, I like IDEs very much (I do prefer the X+sawmill+Emacs+make+bash+... IDE, but the others were nice at the time too). I was fairly surprised that they actually had regexp search in, but the joy ended the second I needed to pipe input from one search into another, or just search all files matching a specific pattern... There are no pipes in the GUI unfortunately.
I agree that you don't want to do repetitive typing yourself if it can be avoided. If you could click a button (or preferably, as you already have your hands on the keyboard, just press a specific key) to perform some operation, that is as a starting poing a ``good thing''. This is actually what Emacs tries to do, and that's why you use C-s and C-r for searching, and "C-c C-v i" (longer sequence for less frequently required function) for inserting new files in version control. I don't agree that Emacs is entirely nice here, I just haven't found a better editor for code yet (yes, I use vi for config files and kernel code, but besides that it's emacs all the way).
However (!) If I did find a better editor, it would plug right into my existing framework of window manager, bash, grep, gazillions of other tools. You can't hot-plug the editor in VS.
Anyway, I did really try, believe me, I'm an open minded person, but Visual Studio is in my oppinion a *very* poor substutitute for a *the*real* IDE, for someone who knows various IDEs generally and *the*real* IDE specifically.
I don't know about sticky breakpoints, I rarely debug code (that way). I'd be surprised if GUD didn't supply such a feature (GUD is actually a little fun because while being the Grand Unified Debugger, in Danish it is also the word for God, so, I found God when searching for a debugger
The point about repetitive work I think needs another angle of view. Yes, we want to avoid it, and *no* you definitely do not want to type the same stuff over and over again in a shell.
Now, to rename the define F1OO to BAR1, F200 to BAR2 in all
find . -name '*.[chf]' | xargs perl -pie 's/F(\d)OO/BAR$1/'
AND THAT IS IT ! If your IDE doesn't have a button that says ``replace text matching some pattern with another pattern, in all files matching some pattern'', then *you* will have to do your repetitive work clicking buttons whil I have moved on to the next problem a long while ago.
Sure, you need to grasp regular expressions. But if you want to get real work done in any environment (now that even VS is catching on), you might as well do that anyway. And then you need to grasp pipes. Well, start by thinking of it as, say, a pipe.
Not meaning to be sarchastical (if I could only spell that), but I think most of the arguments in this discussion are based on people seeing the problem from some very narrow viewpoint. I may well be doing the same, but for now I'm convinced that I'm not, and looking forward to being proved wrong.
The whole point of my argument is, that Emacs is not an IDE, neither is bash, or grep, or sawmill.
But those and a lot more tools together *form* an IDE, which you have right in front of you already if you have those tools installed.
...when we already have the ultimate one at hand: X + some window manager + some editor + make, shells, and tons of utilities.
:)
I feel that people can't see the forest because all the trees are in the way.
With Glade (or equivalents for Qt or VDK or whatever) for GUI design, Emacs/Vi/Joe/..., the make utility, and the incredible number of small utilities (egrep, find, perl -pie, etc.) in any combination you like combined with the power of the shell, you have an absolutely fantastic well integrated development environment that can not only suit most needs, but also be _made_ to suit unforseen needs.
The traditional IDEs are mere subsets of the *real IDE*, and they are good for beginners, no doubt. It's easy to tell someone that to compile press F9, and if you want to do regular expression substition on all files containing the word "SOMETHING", well, you can do it by hand.
For the rest of us, we can set up emacs to call make when we press F9, and we _can_ actually automate arbitrarily complex search or replace commands.
The power of shells and editors all in windows (so you can have multiple shells and editors on-screen simultaneously), where shells can run arbitrary combinations of utilities should not be underestimated.
Instead of re-editing and re-compiling you program to only show specific debug output, you stick an |egrep 'pattern' behind it when you run it. Nice and easy. I could go on forever with that
Still, better to have people developing new APIs than having them sell crack to children and what not. I would prefer if people could focus on improving the fantastic IDE we already _have_ though... There should be plenty of opportunity to come up with new small utilities and improvements to the window managers, to the build tools, to the editors, and to things we haven't even thought of yet.
I've got to ask: Why GNU/Linux ?
I know you couldn't call it a Beowulf if you chose otherwise, but there's got to be more to it than that (I guess). What other OS'es did you consider, and why did you pick GNU/Linux ?
The only way you can ``contribute'' to your GPL'ed software, is to make the changes under the GPL too. You employer will simply have to accept that any modifications you do while at work, will be licensed under the GPL.
;)
:)
Of course, your employer will most likely hold the copyright on those changes, but the changes will be under GPL.
You can then merge the changes into your GPL software, for which you hold the original copyright, stating that your company now owns some of the GPL'ed code in there. That is, if you approve of the changes of course
This is really a wonderful example of how well the GPL works, even though it's fairly restrictive, it solves these issues simply and efficiently. It's perfectly normal for a GPL program to be owned by a lot of people, and that's perfectly fine as long as all the contributers accept that the code they own will be licensed under GPL as well.
In fact, the more people who own code in a GPL program, the harder it will be to actually change the license, as all owners must agree to the change.
Your company will probably be happy to hear that there is no problem in you working on the software, and that they get to keep the copyright on anything you write in company time. Of course, they must accept that their code is GPL'ed, but that's one small camel them must swallow, and seen in the light that they got to use an existing code base for no charge at all, it shouldn't be too hard.
Your real problem is when the company wants a change that you would not approve of wearing your non-company hat. I guess we can't help you with that
The Samba team doesn't protect their own confidential trade sectrets very well, and surely they could use this spec if they protected the implementation equally well. Microsoft knows that of course. But hey, they're not just giving away competitive advantages all of the sudden. It's a PR stunt for sure, but it's not good enough to be just that. There _must_ be something important which is not in the spec, or which is different in the spec. What could it be ? I haven't seen the spec myself and I don't know Kerberos stuff, but somehow we're going to find out when Samba implements the spec and some sort of hell breaks lose. My best guess would be that it is related to security - call me detective ;) Could there be some blatant backdoor inherent in an implementation following the spec ? Let's hear what people who know Kerberos and the spec say...
...and that's why english is and will be the language of the internet.
English will change of course, with new words meaning new things.
For many years to come, the people building the net will be technicians of some kind. They will be working with programming languages, markup languages, and hardware. I have yet to see a real-world ``computer-language'' (programming or mark-up) that isn't based on english.
I'm not native english myself, but I tend to write source code comments and program output in english anyway. So anyone using or digging into programs I've written, will be using english too. I see everyone else doing the same thing.
Sure, the technicians are not the ones necessarily deciding the language of the program input/output in an application, but I bet that as soon as you look under the hood of 90% of the non-english programs out there, you'll see comments in english still. As long as more than a few people have to work with code like that, english will be the common language of the many.
Even if you decide to not use english, you still will:
open(OUTF, "min_fil") or die "Kunne ikke åbne min_fil";
Sure, some company tried to translate the macro language of their international products into using words from the languages of each of the translations. I have yet to meet someone who found that anything but catastrophic. Macro packages for the english version wouldn't run on the german version and vice versa. Even worse, you couldn't share experiences across borders, or read foreign language books about the macro language.
Anything that constrains the benefit of communication between people to within national borders, is doomed. Be it a macro language, or a nationalized internet.
That's what the vector computers do, such as the older Crays or Fujitsu ones. They don't have this wuzzy cache stuff, they just have a few GB of equally fast memory, and then a several hundred instruction deep pipeline.
It's great for matrix multiplications, but it sucks for problems that won't fit into an extremely deep pipeline (most discrete algorithms, eg. 90% of the stuff 90% of people use)
If you have high latency on your memory without a deep pipeline to make up for it (in order to prefetch loooong ahead of time) you'll suffer. And if you run the software most people do who don't do weather forecasts or fusion weaponry, you'll even suffer if you had that pipeline (which you don't). If RDRAM has high latency, it won't make the desktop. Not even marketing will make that happen.
Others have already answered the question with reference to POSIX, but I just thought I'd thow in my two Euro as well...
Recently having ported software between Linux, FreeBSD and NT, I have developed my own idea of what a ``UNIX'' is. It's simplicity most of all. Everything is a file, and most calls that work on file descriptors work on _all_ file descriptors. You can make a select() call on a file, a pipe, and a socket. This is impossible on NT, because files are HANDLEs, sockets are SOCKETs, HANDLEs from anonymous pipes cannot be used for select() like calls (only named pipes there). Why this diversity in the API ?
Running a daemon simply requires you to start up the executable with an "&" if it doesn't support forking to background by itself. I have a routine that does this on UNIX as well as on NT. The UNIX code is perhaps 5-10 lines, and the NT code is roughly 150. On NT you must specifically talk to the service control manager, ask it to ask your program to ask it to ask the program to do all kinds of strange things. Horrible, and inflexible to the extreme.
The system calls on UNIX take a minimum necessary number of arguments, and perform some action fairly much as you would expect it to. An average system call on UNIX probably has, say, 3-4 arguments. I haven't counted the average on NT, but I'd guess it's 6-7 arguments there. This is not because NT is more advanced, but because IMO the design of Win32 is flawed.
As an example, to start up a program on UNIX, you'll write something like (dumbed down):
if(!fork())
exec("my_program", arguments, environment)
Two system calls that perform a very clear and simple task each, taking 0 and 3 arguments.
The similar code on NT is something along the lines of a call to CreateProcess() which takes 10 (ten!) arguments. These arguments are: program name, command line and environment as on UNIX. Besides, you'll have to pass arguments such as current directory, process security attributes, thread security attributes, filehandle inheritance flag, creation flags, etc. etc. My favorite is that you have to pass an argument specifying the Window Size (!!) of your new process... I nearly pissed my pants when I saw that.
UNIX system calls are fairly consistent. Usually they will return either a 0 pointer, or the integer -1, if the call fails (depending on whether the call returns a pointer or an integer). On NT the calls return either INVALID_PROCESS_HANDLE, INVALID_FILE_HANDLE, INVALID_SOCKET, FALSE, 0, -1, or whatever the failure-return-code-of-the-day was when some call was last rewritten. Error codes can be retrieved from errno on UNIX, while on NT they come from GetLastError() usually (with some exceptions I've happily forgotten about), unless of course it was a socket call that failed, in which case the errorcode can be retrieved from WSAGetLastError(). Sigh.
The point I'm trying to make here is, that to me UNIX stands for a _fairly_ consistent and well designed API. Win32 is neither well designed nor consistent, and porting command line utilities to NT is not going to make it UNIX, not by a long shot.
The GUI wasn't new technology either, neither was pens or a 32-bit OS.
In the public awareness, microsoft already has a gaming console, the x-box, and in 2001 they have been on the market for more than a year. This is what counts. It's lame but it counts, and it's called marketing, like it or not.
By the time the x-box eventually hits the streets (by that time it will have a new name though, because the x-box will get bad press sometime before, because of better specs (or whatever) from the established console companies) people will remember that Microsoft has actually been in the console business for a long time, regardless of the fact that the ``y-box'' is the first thing to actually hit the streets.
Hmm... Now that you're saying it, I actually remember seing the _getspecific call in pthreads a few days back.
:)
My best guess is that it's an implementation that was unsuited for what the thread was all about: multiple threads protecting their hardware graphics contexts using thread private storage. I'm pretty sure that if the pthreads implementation was sufficient, there wouldn't have been such a thread on LKML
Just what seems slow as hell ?
Forking a whole new process on Linux is faster than spawning a thread on NT - Check your Linux Journal back-issues for numbers.
The idea is to fork two processes and let them share *some* memory. This should do the same as forking one process, then an additional thread with extra private memory - remembering to keep some of the original memory private for the original thread too.
clone(CLONE_VM) will spawn a new thread in the same address space as the calling thread (the original ``process''). It's the way to create a new thread on Linux. Actually AFAIR fork() uses clone() without CLONE_VM to do a ``real'' fork.
All threads making up a ``process'' share the same memory. Thus you don't have something called thread-private storage. However, separate processes (having one or more threads each) may share memory - thus you have a number of threads sharing some memory while keeping some private. Instead of deciding on privatizing, you decide on sharing. You can perfectly well end up with the same end result, and an uncluttered kernel too.
Well I don't remember the whole thread. But I think the conclusion was that thread private storage (or whatever we choose to call it) was not needed when we had DRI (with proper locking) in the kernel. As for threads and context switches in general, context switches are _fast_ under linux. And if you won't be needing the private storage anyway, they're even uncalled for. It doesn't matter that they improve speed on less well designed architectures, if we have the better design.
There was a mention of IRIX which provides thread-private storage. People who had worked on the IRIX kernel clearly stated that Linux should _not_ go there. It's a horrible thing to do to a UNIX kernel, and much better interfaces can be made instead to make the need for thread private storage vanish.
Agreed 100%!
It was great to finally see someone from a fairly closed-source commercial company (even from a guy who in other companies would have pointy hair) state that OSS is not about price, it's about the O and the S before the S.
I work for a company developing closed-source commercial software, for Linux, BSD, NT, and whatever else people want. I (we actually) work on Linux and BSD, *then* port to NT. Why ? Development is _so_ much easier when you have the sources for your platform and tools handy.
Besides, having filed bug reports for both GCC and MS VC++, I can also say that in my experience the community support is not just superior, it's a whole other dimension of willing and useful support.
It's not just the open source alone that matters, it's also the fantastic people behind it. It doesn't matter what you pay for Linux systems (or BSD for that matter), no kind of money could ever buy me this kind of support on a closed source platform. The fact that I don't pay much for Linux is just a nice side effect.
I get *sick* of papers always referring to OSS as ``gratis software'', not Free, not Open. Even though in denmark we have different words for gratis and Free. But hey, they're the people who refer to RMS as a criminal because they've heard he's a hacker...
Now with that said, consider the difference between two processes (two single threads in each their memory space) shaing a chunk of memory (shared memory has been available "always" in Linux and UN*X), and two threads (two threads in a single memory space) having private storage...
Tell me the difference... No, wait, there's none (!)
This was discussed on LKML, and the above is my recap of the conclusion. People focus so much on technology instead of what the technology is intended to do, that they fail to see that thread private storage is meaningless when you have processes and shared memory.
To quote Linus' ending statement:
I'll take portability, sanity and clean design before some "my dick is bigger than your dick" direct rendering argument any day.
- Linus Torvalds (commenting on IRIX, GL and thread-private storage)
Hear, Hear, Brother !
:*( (well, trying was fun too)
I was pretty darn close to starting a reimplementation for X myself a few years ago. I actually mailed Microprose to ask them for the source (no shit!), for some reason I never even got a reply
The two first versions of the game were great, the third one sort of ruined it IMO. If only I had a year or two I didn't know what to do with, I'd be firing up gcc&Mesa and get that baby done with.
Actually doing a reimplementation would probably be the easiest, and by far the most fun. Think about XCom in 1600x1200, MesaGL, original plot, MP3 background music, drooool....
I'd love to ask "Any takers?" but I just _can't_ go into this myself now.
1) Software on a PII is slower than software on an i960 or i486 or M68something ? That's a new one... :)
2) The Linux kernel has excellent caching techniques. Besides, it uses your main memory for caching, so you get the benefit of having a dynamically sized cache, adapting to your needs at any given time
3) A HW controller doesn't magically make all your disks hot swappable. Often people are happy just their system keeps running until some time where they can conveniently take it down and replace failed disks. I'm happy with that
4) No serious sysadmin is going to use anything but csh and a Sparc5. But for the rest of us, the better performing, more flexible, and cheeper solution is definitely something that shouldn't just be ignored.
5) You can build nice RAID-5 sets with IDE, just buy a few extra IDE controllers, use only one disk per bus (to keep good performance), and you're off.
The point of RAID without hotswap is saving you a night of reinstalling and restoring backups. You will have to take the system down to replace the disk, but you can do this at a convenient time. That's worth a lot to many of us. And remember this is often at the price of one extra disk.
Think about it for a second: The overhead imposed on your CPU when doing software RAID is something like going thru one extra layer in the FS-> VFS-> block device-> (RAID)-> buffer/cache-> device chain. It's something like 30 extra lines of C code (give and take). This is just _not_ going to make your CPUs peg to 100%. Something else must have been doing this to you, I don't know what, but I've _never_ heard anyone report this. For the record my own box with 4 4.5G IBM SCSI disks do 30+ MB/s sustained transfers on RAID-0. For me the speed limit is here because of crappy memory bandwith on the aging PPro system.
SW RAID should work with IDE, SCSI, and any combination you please. Your experience sounds pretty strange.
If you didn't patch the 2.2.14 kernel and didn't use an -ac patch, then you've been running the old RAID code. This is inferior to the 0.90 code available as patches, but RAID-0 performance should be comparable. My guess is something else in your setup caused this CPU hogging. If it's just misconfiguration of the RAID, it's pretty interesting as I've seen noone else hitting the problem you describe.
Old habits die hard I guess. I stopped counting the number of times people in disbelief have seen Software RAID wipe the floor with their HW solution, performance wise. Drop by the linux-raid list (archives eventually) and see for yourself some day.
Even if we agree that it's not for production (I don't agree, but let's assume so for a second) you still didn't want to use your hand-patched ATA/66 card for production either now, did you ?
If you want to swap systems, SW RAID is just as fine. Swap the disks and the other system will boot on them as well. Wether they're attached to a SCSI controller with RAID capability or not makes no difference. The other system will see the volumes too, the configuration doesn't change magically when moved from one system to the other...
IDE lacks hotswap capability, that's why it's often considered a bad idea. But compare it to a production server _without_ RAID, and suddenly it's one hell of a lot better. You can take the machine down some time convenient, and you won't be reinstalling and restoring backups all night.
Go with Linux Software RAID instead, and save even more money. The 0.90 code (which works very well) is available as patches to the 2.2 series, and is currently being integrated into the 2.3 series.
This will support RAID-linear, -0, -1, -4 and -5. It will work with your ATA cards as well as with your SCSI ones. The IDE layer in Linux is stable enough to survive any disk failure I've ever seen, so stability is as good as it gets.
Besides, Software RAID solutions are usually somewhere between faster and _much_ faster than HW ones. Back in the old days it was a gain to do RAID management in software on an auxillary processor (``hardware'' RAID), but these days your average 400MHz PII won't even notice the extra workload (it's neglible to running ``top'' etc.).
Check out the HOWTO at http://ostenfeld.dk/~jakob/Software-RAID.HOWTO. It's also in the process of getting into the LDP, so we'll be nicely set up for when 2.4 hits the street.
NT has had symlinks for a long time. No hardlinks though. This seems more like `automatic' hardlinks to me...
;)
Anyway, they added mountpoints to Win2K too. Finally the end of drive letters...
And they're skipping WINS in favour of DNS (with their own extensions though).
They're getting there. In a few decades NT might actually become a nice UNIX. Now if I could just see the kernel code for the syscalls I think behave funny, like in any decent kernel
RAID 0.90 is in the process of being merged.
Linear and RAID-0 should compile and work (I've only tried RAID-0 myself, on 2.3.47). There was a little hazzle with autodetection/boot support, but other than that, it worked.
The other RAID levels should be on their way.
Oh, and the HOWTO should be on it's way into the LDP now.