sh is pretty much guaranteed to be on any UNIX or UNIX like machine you will ever encounter.
Yes, but sh doesn't get the job done--it's not a scripting language in the sense of Perl or Python or Tcl.
Then why not Python or TCL or Ruby or CobolScript.
Sure, why not. I really don't care. I actually don't like Perl. Pick one scripting language and use it consistently. But writing the entire operating system base in shell and C because FreeBSD can't decide on a scripting language to include is just stupid. This isn't V6 UNIX anymore and people don't wear bell-bottoms. Move into the 21st century, guys.
There is no safe way to handle a segmentation fault because your program should not throw segmentation faults in the first place. There is nothing a Java program can do when it catches an OutOfMemoryException either.
Of course it can; even C is in a well-defined state when memory allocation fails.
The problem in C is that for most other runtime errors, the entire program is in an undefined state after they occur, and the runtime errors aren't even detected reliably. In contrast, most other programming languages leave programs in well-defined states after the occurrence of errors detected by the runtime.
In any case, C programmers generally achieve fault isolation by separating their program into multiple processes.
Yes, traditionally, that was true. Today, they do so less and less: more and more programs use plug-ins, components, and COM-like constructions. Look at Mozilla, the Gimp, the Linux kernel, or OpenOffice.
Furthermore, lack of fault isolation is only part of the problem with C, another very serious problem is the lack of reliable detection of common runtime errors like pointer errors, memory management errors, type errors, and index errors. And C never has had good answers to that problem--you just get the wrong results.
C really has some serious deficiencies. Those didn't matter when UNIX started--programs were small, incorrect results mattered less, there were no dynamically loadable software components, runtime error checking was expensive, and lots of separate little command line utilities provided some fault isolation. The world has changed radically, and it's time Linux changes with it. Even Microsoft has seen the light (although I'm unconvinced that a JIT/CLR is the right answer; a batch-C# compiler would be a better choice IMO).
The notion that you can recover from errors that you didn't anticipate is flawed. When your application cannot complete the user's request because of some unexpected error the game is already over.
Absolutely false. Let's say I write an on-line banking application that loads a third-party communications module. In a reasonable programming language, if I invoke the third-party communications module and it crashes with some unexpected error, I can just tell the user that there is a problem with that module and the user can go on using the rest of the application. In C, if there is an error in a dynamically loaded module, anything could be corrupted.
The reality is that the most disastrous errors generally do not occur at the hardware, OS or language levels, but at the application level.
For applications written in C/C++, that is absolutely true.
From a pragmatic perspective there is no difference between "Safety exception! Program shut down!" or "Type error! No such method!" and the good old "Core dump".
When I get an exception in, say, Java, the program is still in a state that is completely well-defined. That means that well-designed programs can recover safely even from unexpected errors.
In contrast, when a C program gets a segmentation fault or other pointer error, the entire program state is undefined; there is nothing the program can do safely to recover from the error.
And even worse is the fact that C fails to guarantee that errors resulting in undefined program states are even detected. Concretely, you can have a pointer error, it messes up some data structure, and nothing may ever signal that error--it will just corrupt your bank account or do something else bad.
Basically, your attitude is both common among C programmers and completely uninformed. C error handling is not like error handling in other high-level languages: C guarantees much less, and the consequences of that are dire for the quality and security of C programs.
When you are beholden to some measure of reliability that most people will never need or even want, maybe.
We aren't talking about some esoteric notion of reliability. We are talking about the fact that it takes years to get a new major release of the Linux kernel, Gnome, or KDE out, and they still keep crashing. We are talking about almost daily security holes in Windows and Linux network servers.
It's largely a matter of keeping your eyes on the road.
Well, the quality and timeliness of Windows, Linux, Gnome, KDE, and other large C/C++ projects shows that most C programmers apparently aren't up to the challenge and are falling asleep at the wheel.
Uh. OK. But since at the hardware level this is generally true no matter what language is being used I think this argument is rather specious.
No, the argument is not "specious" at all. When I program in a safe high-level language, then the implementor of the language and runtime has worried about pointer bugs in the implementation of that language once and I never have to think about it. With C, I have to worry about pointer bugs with every single program I write.
OutOfMemoryExceptions, ArrayIndexOutOfBoundsExceptions and NoSuchMethodExceptions break applications just like segmentation faults do. You might argue that the first type of breakage is "better" on the general principle that it yields more predictable behavior, but for the user whose application stops working that's a largely academic distinction.
The distinction is not at all academic. First of all, pointer errors and index errors often do not cause applications to crash, and that is a real problem because those applications may quietly return incorrect results; this is actually quite frequent. Second, in a language with exceptions and fault isolation (like many scripting languages and most languages other than C), when an exception occurs, a well-designed program can safely recover from it even if the detailed cause of the exception was not anticipated by the programmer. In contrast, when you get a segmentation fault in C, all bets are off: there is no safe way to handle a segmentation fault or other C runtime error because the entire program state is undefined.
The lack of reliable error detection and the lack of fault isolation in C really make it exceptionally bad among programming languages as a platform for writing reliable code. There are no few other modern languages that are as bad as C, and few that come close.
Code that was bugfree when it was written may develop bugs over time as a result of subtle changes in requirements or operating environment. The chances of this happening are proportional to the flexibility of the operating environment, i.e. much greater in a scripting environment.
Ah, yes, we can summarize your argument as: "if you just make programming hard enough, people won't write anything worth testing". That may be true, but it's not the way to make software reliable.
The real secret is to minimize the number of things that need testing, which is not something you can do by minimizing lines of code. The relationships, dependencies and exceptions expressed in a single line of Python code may require far more testing than 2 pages of portable C code.
That argument would be admissible if you compared Python to a language with a sound type system and with fault isolation. But C is not such a language: in C, there are potentially relationships between everything anywhere in the code because of pointer manipulation and lack of safety. And those relationships require extensive testing in C, far more than in Python.
Don't get me wrong: I don't hate C as much as it may sound. C is fine for many of the purposes it was originally developed for. But holding it up as an example of something that is better suited to developing reliable software than Python or most other scripting languages is just a joke. The absence of buffer overflows, stale pointers, and index errors in Perl and Python alone dwarfs any problems Perl may have relative to C. Perl, Python, and other scripting languages have plenty of problems, but they are still enormously better than C in terms of reliability.
The benefits of scripting over languages such as C are grossly overrated.
No, they aren't. One might say that the benefits of scripting languages over Java, C#, Modula-3, or any number of other languages are grossly overrated. But given C's frail type system and non-existent error checking, it's easier to develop reliable code in even a bad scripting language like Perl than in C.
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs.
That's like driving with a safety belt on while taking driving lessons, and then taking it off once you get your license. The only way to ensure safety and reliability is to have a consistent type system and consistent error checking built into the language. Perl's error checking is not all that great, but C is much worse.
Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
Since when does C have any checks for runtime errors, dependency errors, or incompatible library upgrades? Are you perhaps referring to Linux's shared library versioning? That's not built into C or integrated with the language.
In contrast, many scripting languages have facilities for declaring module versions and dependencies, and they check them.
God only knows why colleges keep churning out students who insist that mashed potatoes are the most flexible material to build a bookshelf...
Probably because the professors that teach those students know something you don't.
Both C and Perl are "mashed potatoes" when it comes to building reliable systems.
Wouldn't the obvious choice be sh scripting, since it is available everywhere,
That's different kinds of scripting. In Perl, I can do almost anything I can do in C: make system calls, deal with dynamic libraries, manipulate binary data, etc.
It's just that if you do a minimal install, it's not there, which if you're talking 100 megs and Perl is another 12 is a good amount you might not want.
There is a lot of stuff in those 100M that I don't want either--people need to make choices. I just think the FreeBSD choice of making the base install consist of C and shell scripts is a bad one and will not serve FreeBSD in the long run.
If you want a small base install, the best thing you can do is pick a scripting language and rewrite as much stuff in it as possible: init, cron, various command line utilities, etc. Besides generally making the install smaller, that has the other advantage that you can have a system that is easily fixable on-the-fly without having a complete C compiler installation.
And also for those of us who don't want Perl on our systems there's no extra work of removing it, adding stuff onto a minimal base is much easier than having 400 megs of junk on my system which i then have to remove.
I don't like C/shell-based base installs precisely because they end up being bloated, messy, and hard to modify; it's just the wrong direction to go IMO.
FreeBSDs decision to move Perl from the base system to the ports tree was because it was easier to handle that way, both for developers and users. It was not about not supporting it anymore.
Not including it in the base system is what I mean by "not supporting it": I want some scripting language be available out of the box on any desktop or server, and Perl is the obvious choice.
Indeed. The base system works without PERL (beginning with 5.0-REL).
I don't view that as a plus. I think a base OS install should come with a full-featured scripting language that gives access to all OS facilities, and as much stuff as possible should be implemented in it.
If you think about it, it's not a bad system design decission to try to make the base-install leaner.
The base install would get a lot leaner if it were based on a scripting language and a lot of the utilities were implemented in it--several floppy distributions that have switched from C-based utilities to scripting-based utilities have proven that.
And for desktop and server installs, Perl is the obvious choice for a scripting language right now. Even if you don't like Perl (and there is a lot there that is not to like), pick some other scripting language, any scripting language. But converting utilities into C code is just completely the wrong direction.
because the 5 second delay while my xterm redraws after I drag a window in front of it on XFree86 is so amazingly fast compared to OS X
That's nonsense; xterm redraws have been imperceptible on regular hardware for years.
OS X which has minimal redraw latency even with transparent windows
Yes, it does, by shoving graphics content into the server. But that's not drawing speed, that's redrawing speed. You can tell X11 to do the same thing, it just happens to be disabled by default because it's pointless on a properly configured system.
How exactly is "Linux" easier to install and maintain? Portage is available for OS X - the exact same package management system for a popular desktop distro.
The problem is that OS X package management isn't consistent: some applications are updated by Apple, others are updated by hand, yet others have their own built-in update systems, and then there are several ported Linux and BSD package managers. The upshot is that maintaining an OS X system requires a lot of manual work, while Linux systems update themselves completely automatically and consistently.
In any case, I think most people will find that all the applications that they could possibly miss (usual POSIX console utilities and emacs) are there, along with some much improved ones (xchat) and a whole new plethora of cocoa apps - that perhaps they didn't know they wanted;)
There is a lot of UNIX/Linux software that doesn't work on OS X and is a pain to port. Problems are non-UNIX implementations of audio, video, I/O, and just general differences in header files and libraries.
After having built a fully optimized gentoo system (2.4.21-ck3, XFree86 4, fluxbox) for my Athlon XP 2000+, I was bitterly disappointed to note the above noted redraw lag. IM(NS)HO, OS X desktop interactivity is faster.
You are probably using an unaccelerated video driver or have some other configuration problem. You can't blame Linux for that. If you want good performance with no hassles, buy a system that comes with Linux support out of the box.
Well, the real 12" Powerbook killers have been around since before the 12" Powerbook even existed: x86-based laptops that are more powerful and cost about the same amount of money. The Sony is amazing because it is considerably lighter and smaller while still having a DVD drive.
As for ports, the 12" Powerbook lacks both USB2 and PCMCIA, and I consider that a very serious limitation no matter what other features it has.
While I'm all for writing more command line utilities in general (as opposed to the kind of cumbersome GUI stuff everybody does), these particular kinds of command line tools are usually done using awk. For example, to sum up a column of numbers, write:
Your mathematical utilities would be more useful if you had programmed them in C. Your choice of language will limit their adoption. Basically because using Perl scripts is not as fast as calling compiled C programs.
I have actually written a lot of this kind of code, working with huge datasets, and you are simply wrong. The performance of these kinds of utilities is dominated by I/O, not CPU. Furthermore, even the CPU-intensive parts of these utilities (conversions, etc.) are implemented in highly optimized C code inside Perl.
Because FreeBSD doesn't ship Perl as standard part of their distribution anymore, it'll be likely that your utils will not get included in any BSD software because it would pull in Perl.
I think Perl is a pretty awful language, but not including it in FreeBSD strikes me as a stupid decision. Perl is useful and works well across many systems. It's also not particularly big. If FreeBSD doesn't include Perl in the standard install, then FreeBSD has a problem, not people who write scripts in Perl.
What is BSD doing instead? Implementing all utilities in C? Gee, that's bright: let's create lots of unnecessary work for ourselves, increase maintenance hassles, make it really difficult to use good algorithms, make sure that there are plenty of opportunities for pointer bugs. That's negative progress: operating systems need less C programming, not more.
Are you suggesting that Linus would sue Red Hat to get them to stop shipping the Linux kernel to their customers?!
You bet: if SCO demonstrates that there is SCO copyrighted code in the Linux kernel, then they will have demonstrated that there is non-GPL'ed code in the Linux kernel. I fully expect that anybody, including RedHat, that knowingly ships the Linux kernel with non-GPL'ed code would get sued.
If you really need less weight and possibly longer battery life, the sony is for you...oh, and remember that extra $400...
Yes, that's what the extra $400 are for with the Sony: the smaller size and the lighter weight. If you want something more directly comparable to the 12" Powerbook, you can get any of a number of x86-based laptops with pretty much the same size and price, the Fujitsu P5000 being one of them.
I'm sorry--while the 12" Powerbook is a reasonably nice laptop, but it is nothing special either in terms of pricing, features, or size.
Every printer, whether laser or ink-jet or anything else, costs a certain amount of money to operate per page. Manufacturers are pricing printers in different ways: some have bigger up-front costs and smaller ink costs, others do it the other way around and charge a premium for the ink.
If you don't erroneously assume that a cheaper printer translates into a cheaper product, you are fine: just calculate what the per-page costs are and pick the cheapest one for your needs. You can save some money with refills, but at the cost of more hassle on your part; you yourself have to know whether you want to bother. I generally don't. Once ink costs are of the same order of magnitude as the paper, I really don't care that much anymore.
Yes, it does. That's because it is considerably nicer hardware: 1.5 pounds lighter (3 pounds vs. 4.6 pounds), higher resolution screen, more ports.
Show me a Mac user who actually wants a Windows machine, or better yet, wants to pay *more* for one?
You're, of course, right: this machine is not a 12" Powerbook killer. Nothing could be a 12" Powerbook killer because Mac users are Mac users and they buy Apple no matter what.
Why don't I ever see something like this: Pentium III 500MHz 20GB Harddrive 128MB RAM 12 inch screen 4lbs or less And some crappy 4MB video for $500
You don't see that because slow chips aren't actually cheaper than current generation chips: the cheapest way of making a laptop is out of the highest-volume components, and those happen to be faster. In fact, if you try to get really old chips, it gets really expensive again.
However, some manufacturers are trying. VIA has had success with their low-cost Mini-ITX boards, and they are trying to push the same concept for laptops and tablets.
Apple's 12" Powerbook costs $1,600 ($1,400 for students), while the new Sony Vaio is expected to cost around $2,000.
That's probably because the Sony hardware is quite a bit nicer: 3 pounds vs. 4.6 pounds, 1280x768 screen vs. 1024x768 screen, PCMCIA slot vs. no PCMCIA slot, USB2 vs. no USB2. The difference in weight alone is a huge difference and should more than account for the price difference.
If you want something directly comparable to the 12" Powerbook, the Fujitsu P5000 is the same price and the same weight. And the Fujitsu P2000 is actually smaller, lighter, and cheaper than the 12" Powerbook (although has somewhat fewer features).
Exactly what is so "proprietary" about Mac OS X that is scaring you away?
Well, the audio and video APIs, for example, which are still based on Cocoa and are a pain to use. And the Mac doesn't use an X11 desktop, it only runs X11 apps under Aqua, so X11 apps don't have good desktop integration. And OS X graphics isn't exactly fast. And on and on.
Overall, I have found that OS X is usable as a sort-of UNIX laptop, but less than ideal. Get one if you need to run OS X apps. If all applications you want to run are Linux/UNIX apps, an x86 laptop running Linux is cheaper, faster, and easier to install and maintain.
Interesting that Apple's notebooks (and mp3 player) are now the standard others are compared against.
I think that has more to do with the slow pace at which Apple rolls out new models than any kind of technical issues. As a result, every one of Apple's handful of laptops receives much more exposure and marketing dollars than any other model.
Don't get me wrong: the 12" Powerbook is pretty nice hardware, but there has been plenty of really nice hardware in the PC world as well. And the Sony beats thes 12" Powerbook hands-down in pretty much every area as far as I'm concerned.
Now you, too, can run an unaccelerated window system (Qt+DirectFB) that runs only a tiny fraction of the software that runs on X11, has much less functionality, and that requires you to pay big bucks to Troll Tech in order to develop commercial apps.
With brilliant ideas like that in the free software community, who needs enemies like Bill Gates trying to kill Linux on the desktop?
Problems with SCO's claim are well documented, and I cannot imagine that they intend to win this, but they have every right to issue a license for their own work (if it is) and it would mean exactly what they claim it would mean in that case. [...] It's not *your* distribution of it that is at question, it is *your vendor's* distribution to you. If that was not legit, then you cannot reasonably use the software.
Right. And my point is that if SCO can legitimately issue you a license on the code, then your vendor's (RedHat, etc.) distribution of Linux to you would not be legit under the GPL.
So, SCO can't really make money off this: they could theoretically keep you from using Linux if they had intellectual property rights, but a business model where RedHat distributes Linux and you need an SCO license to actually run it simply does not work under the GPL because RedHat cannot distribute Linux under those conditions.
Slashdot Mirror
sh is pretty much guaranteed to be on any UNIX or UNIX like machine you will ever encounter.
Yes, but sh doesn't get the job done--it's not a scripting language in the sense of Perl or Python or Tcl.
Then why not Python or TCL or Ruby or CobolScript.
Sure, why not. I really don't care. I actually don't like Perl. Pick one scripting language and use it consistently. But writing the entire operating system base in shell and C because FreeBSD can't decide on a scripting language to include is just stupid. This isn't V6 UNIX anymore and people don't wear bell-bottoms. Move into the 21st century, guys.
There is no safe way to handle a segmentation fault because your program should not throw segmentation faults in the first place. There is nothing a Java program can do when it catches an OutOfMemoryException either.
Of course it can; even C is in a well-defined state when memory allocation fails.
The problem in C is that for most other runtime errors, the entire program is in an undefined state after they occur, and the runtime errors aren't even detected reliably. In contrast, most other programming languages leave programs in well-defined states after the occurrence of errors detected by the runtime.
In any case, C programmers generally achieve fault isolation by separating their program into multiple processes.
Yes, traditionally, that was true. Today, they do so less and less: more and more programs use plug-ins, components, and COM-like constructions. Look at Mozilla, the Gimp, the Linux kernel, or OpenOffice.
Furthermore, lack of fault isolation is only part of the problem with C, another very serious problem is the lack of reliable detection of common runtime errors like pointer errors, memory management errors, type errors, and index errors. And C never has had good answers to that problem--you just get the wrong results.
C really has some serious deficiencies. Those didn't matter when UNIX started--programs were small, incorrect results mattered less, there were no dynamically loadable software components, runtime error checking was expensive, and lots of separate little command line utilities provided some fault isolation. The world has changed radically, and it's time Linux changes with it. Even Microsoft has seen the light (although I'm unconvinced that a JIT/CLR is the right answer; a batch-C# compiler would be a better choice IMO).
The notion that you can recover from errors that you didn't anticipate is flawed. When your application cannot complete the user's request because of some unexpected error the game is already over.
Absolutely false. Let's say I write an on-line banking application that loads a third-party communications module. In a reasonable programming language, if I invoke the third-party communications module and it crashes with some unexpected error, I can just tell the user that there is a problem with that module and the user can go on using the rest of the application. In C, if there is an error in a dynamically loaded module, anything could be corrupted.
The reality is that the most disastrous errors generally do not occur at the hardware, OS or language levels, but at the application level.
For applications written in C/C++, that is absolutely true.
From a pragmatic perspective there is no difference between "Safety exception! Program shut down!" or "Type error! No such method!" and the good old "Core dump".
When I get an exception in, say, Java, the program is still in a state that is completely well-defined. That means that well-designed programs can recover safely even from unexpected errors.
In contrast, when a C program gets a segmentation fault or other pointer error, the entire program state is undefined; there is nothing the program can do safely to recover from the error.
And even worse is the fact that C fails to guarantee that errors resulting in undefined program states are even detected. Concretely, you can have a pointer error, it messes up some data structure, and nothing may ever signal that error--it will just corrupt your bank account or do something else bad.
Basically, your attitude is both common among C programmers and completely uninformed. C error handling is not like error handling in other high-level languages: C guarantees much less, and the consequences of that are dire for the quality and security of C programs.
When you are beholden to some measure of reliability that most people will never need or even want, maybe.
We aren't talking about some esoteric notion of reliability. We are talking about the fact that it takes years to get a new major release of the Linux kernel, Gnome, or KDE out, and they still keep crashing. We are talking about almost daily security holes in Windows and Linux network servers.
It's largely a matter of keeping your eyes on the road.
Well, the quality and timeliness of Windows, Linux, Gnome, KDE, and other large C/C++ projects shows that most C programmers apparently aren't up to the challenge and are falling asleep at the wheel.
Uh. OK. But since at the hardware level this is generally true no matter what language is being used I think this argument is rather specious.
No, the argument is not "specious" at all. When I program in a safe high-level language, then the implementor of the language and runtime has worried about pointer bugs in the implementation of that language once and I never have to think about it. With C, I have to worry about pointer bugs with every single program I write.
OutOfMemoryExceptions, ArrayIndexOutOfBoundsExceptions and NoSuchMethodExceptions break applications just like segmentation faults do. You might argue that the first type of breakage is "better" on the general principle that it yields more predictable behavior, but for the user whose application stops working that's a largely academic distinction.
The distinction is not at all academic. First of all, pointer errors and index errors often do not cause applications to crash, and that is a real problem because those applications may quietly return incorrect results; this is actually quite frequent. Second, in a language with exceptions and fault isolation (like many scripting languages and most languages other than C), when an exception occurs, a well-designed program can safely recover from it even if the detailed cause of the exception was not anticipated by the programmer. In contrast, when you get a segmentation fault in C, all bets are off: there is no safe way to handle a segmentation fault or other C runtime error because the entire program state is undefined.
The lack of reliable error detection and the lack of fault isolation in C really make it exceptionally bad among programming languages as a platform for writing reliable code. There are no few other modern languages that are as bad as C, and few that come close.
Code that was bugfree when it was written may develop bugs over time as a result of subtle changes in requirements or operating environment. The chances of this happening are proportional to the flexibility of the operating environment, i.e. much greater in a scripting environment.
Ah, yes, we can summarize your argument as: "if you just make programming hard enough, people won't write anything worth testing". That may be true, but it's not the way to make software reliable.
The real secret is to minimize the number of things that need testing, which is not something you can do by minimizing lines of code. The relationships, dependencies and exceptions expressed in a single line of Python code may require far more testing than 2 pages of portable C code.
That argument would be admissible if you compared Python to a language with a sound type system and with fault isolation. But C is not such a language: in C, there are potentially relationships between everything anywhere in the code because of pointer manipulation and lack of safety. And those relationships require extensive testing in C, far more than in Python.
Don't get me wrong: I don't hate C as much as it may sound. C is fine for many of the purposes it was originally developed for. But holding it up as an example of something that is better suited to developing reliable software than Python or most other scripting languages is just a joke. The absence of buffer overflows, stale pointers, and index errors in Perl and Python alone dwarfs any problems Perl may have relative to C. Perl, Python, and other scripting languages have plenty of problems, but they are still enormously better than C in terms of reliability.
The benefits of scripting over languages such as C are grossly overrated.
No, they aren't. One might say that the benefits of scripting languages over Java, C#, Modula-3, or any number of other languages are grossly overrated. But given C's frail type system and non-existent error checking, it's easier to develop reliable code in even a bad scripting language like Perl than in C.
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs.
That's like driving with a safety belt on while taking driving lessons, and then taking it off once you get your license. The only way to ensure safety and reliability is to have a consistent type system and consistent error checking built into the language. Perl's error checking is not all that great, but C is much worse.
Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
Since when does C have any checks for runtime errors, dependency errors, or incompatible library upgrades? Are you perhaps referring to Linux's shared library versioning? That's not built into C or integrated with the language.
In contrast, many scripting languages have facilities for declaring module versions and dependencies, and they check them.
God only knows why colleges keep churning out students who insist that mashed potatoes are the most flexible material to build a bookshelf...
Probably because the professors that teach those students know something you don't.
Both C and Perl are "mashed potatoes" when it comes to building reliable systems.
Wouldn't the obvious choice be sh scripting, since it is available everywhere,
That's different kinds of scripting. In Perl, I can do almost anything I can do in C: make system calls, deal with dynamic libraries, manipulate binary data, etc.
It's just that if you do a minimal install, it's not there, which if you're talking 100 megs and Perl is another 12 is a good amount you might not want.
There is a lot of stuff in those 100M that I don't want either--people need to make choices. I just think the FreeBSD choice of making the base install consist of C and shell scripts is a bad one and will not serve FreeBSD in the long run.
If you want a small base install, the best thing you can do is pick a scripting language and rewrite as much stuff in it as possible: init, cron, various command line utilities, etc. Besides generally making the install smaller, that has the other advantage that you can have a system that is easily fixable on-the-fly without having a complete C compiler installation.
And also for those of us who don't want Perl on our systems there's no extra work of removing it, adding stuff onto a minimal base is much easier than having 400 megs of junk on my system which i then have to remove.
I don't like C/shell-based base installs precisely because they end up being bloated, messy, and hard to modify; it's just the wrong direction to go IMO.
FreeBSDs decision to move Perl from the base system to the ports tree was because it was easier to handle that way, both for developers and users. It was not about not supporting it anymore.
Not including it in the base system is what I mean by "not supporting it": I want some scripting language be available out of the box on any desktop or server, and Perl is the obvious choice.
Indeed. The base system works without PERL (beginning with 5.0-REL).
I don't view that as a plus. I think a base OS install should come with a full-featured scripting language that gives access to all OS facilities, and as much stuff as possible should be implemented in it.
If you think about it, it's not a bad system design decission to try to make the base-install leaner.
The base install would get a lot leaner if it were based on a scripting language and a lot of the utilities were implemented in it--several floppy distributions that have switched from C-based utilities to scripting-based utilities have proven that.
And for desktop and server installs, Perl is the obvious choice for a scripting language right now. Even if you don't like Perl (and there is a lot there that is not to like), pick some other scripting language, any scripting language. But converting utilities into C code is just completely the wrong direction.
because the 5 second delay while my xterm redraws after I drag a window in front of it on XFree86 is so amazingly fast compared to OS X
;)
That's nonsense; xterm redraws have been imperceptible on regular hardware for years.
OS X which has minimal redraw latency even with transparent windows
Yes, it does, by shoving graphics content into the server. But that's not drawing speed, that's redrawing speed. You can tell X11 to do the same thing, it just happens to be disabled by default because it's pointless on a properly configured system.
How exactly is "Linux" easier to install and maintain? Portage is available for OS X - the exact same package management system for a popular desktop distro.
The problem is that OS X package management isn't consistent: some applications are updated by Apple, others are updated by hand, yet others have their own built-in update systems, and then there are several ported Linux and BSD package managers. The upshot is that maintaining an OS X system requires a lot of manual work, while Linux systems update themselves completely automatically and consistently.
In any case, I think most people will find that all the applications that they could possibly miss (usual POSIX console utilities and emacs) are there, along with some much improved ones (xchat) and a whole new plethora of cocoa apps - that perhaps they didn't know they wanted
There is a lot of UNIX/Linux software that doesn't work on OS X and is a pain to port. Problems are non-UNIX implementations of audio, video, I/O, and just general differences in header files and libraries.
After having built a fully optimized gentoo system (2.4.21-ck3, XFree86 4, fluxbox) for my Athlon XP 2000+, I was bitterly disappointed to note the above noted redraw lag. IM(NS)HO, OS X desktop interactivity is faster.
You are probably using an unaccelerated video driver or have some other configuration problem. You can't blame Linux for that. If you want good performance with no hassles, buy a system that comes with Linux support out of the box.
Well, the real 12" Powerbook killers have been around since before the 12" Powerbook even existed: x86-based laptops that are more powerful and cost about the same amount of money. The Sony is amazing because it is considerably lighter and smaller while still having a DVD drive.
As for ports, the 12" Powerbook lacks both USB2 and PCMCIA, and I consider that a very serious limitation no matter what other features it has.
Your mathematical utilities would be more useful if you had programmed them in C. Your choice of language will limit their adoption. Basically because using Perl scripts is not as fast as calling compiled C programs.
I have actually written a lot of this kind of code, working with huge datasets, and you are simply wrong. The performance of these kinds of utilities is dominated by I/O, not CPU. Furthermore, even the CPU-intensive parts of these utilities (conversions, etc.) are implemented in highly optimized C code inside Perl.
Because FreeBSD doesn't ship Perl as standard part of their distribution anymore, it'll be likely that your utils will not get included in any BSD software because it would pull in Perl.
I think Perl is a pretty awful language, but not including it in FreeBSD strikes me as a stupid decision. Perl is useful and works well across many systems. It's also not particularly big. If FreeBSD doesn't include Perl in the standard install, then FreeBSD has a problem, not people who write scripts in Perl.
What is BSD doing instead? Implementing all utilities in C? Gee, that's bright: let's create lots of unnecessary work for ourselves, increase maintenance hassles, make it really difficult to use good algorithms, make sure that there are plenty of opportunities for pointer bugs. That's negative progress: operating systems need less C programming, not more.
Are you suggesting that Linus would sue Red Hat to get them to stop shipping the Linux kernel to their customers?!
You bet: if SCO demonstrates that there is SCO copyrighted code in the Linux kernel, then they will have demonstrated that there is non-GPL'ed code in the Linux kernel. I fully expect that anybody, including RedHat, that knowingly ships the Linux kernel with non-GPL'ed code would get sued.
If you really need less weight and possibly longer battery life, the sony is for you...oh, and remember that extra $400...
Yes, that's what the extra $400 are for with the Sony: the smaller size and the lighter weight. If you want something more directly comparable to the 12" Powerbook, you can get any of a number of x86-based laptops with pretty much the same size and price, the Fujitsu P5000 being one of them.
I'm sorry--while the 12" Powerbook is a reasonably nice laptop, but it is nothing special either in terms of pricing, features, or size.
Every printer, whether laser or ink-jet or anything else, costs a certain amount of money to operate per page. Manufacturers are pricing printers in different ways: some have bigger up-front costs and smaller ink costs, others do it the other way around and charge a premium for the ink.
If you don't erroneously assume that a cheaper printer translates into a cheaper product, you are fine: just calculate what the per-page costs are and pick the cheapest one for your needs. You can save some money with refills, but at the cost of more hassle on your part; you yourself have to know whether you want to bother. I generally don't. Once ink costs are of the same order of magnitude as the paper, I really don't care that much anymore.
This VAIO costs $700 more than a 12" Powerbook.
Yes, it does. That's because it is considerably nicer hardware: 1.5 pounds lighter (3 pounds vs. 4.6 pounds), higher resolution screen, more ports.
Show me a Mac user who actually wants a Windows machine, or better yet, wants to pay *more* for one?
You're, of course, right: this machine is not a 12" Powerbook killer. Nothing could be a 12" Powerbook killer because Mac users are Mac users and they buy Apple no matter what.
Why don't I ever see something like this: Pentium III 500MHz 20GB Harddrive 128MB RAM 12 inch screen 4lbs or less And some crappy 4MB video for $500
You don't see that because slow chips aren't actually cheaper than current generation chips: the cheapest way of making a laptop is out of the highest-volume components, and those happen to be faster. In fact, if you try to get really old chips, it gets really expensive again.
However, some manufacturers are trying. VIA has had success with their low-cost Mini-ITX boards, and they are trying to push the same concept for laptops and tablets.
Apple's 12" Powerbook costs $1,600 ($1,400 for students), while the new Sony Vaio is expected to cost around $2,000.
That's probably because the Sony hardware is quite a bit nicer: 3 pounds vs. 4.6 pounds, 1280x768 screen vs. 1024x768 screen, PCMCIA slot vs. no PCMCIA slot, USB2 vs. no USB2. The difference in weight alone is a huge difference and should more than account for the price difference.
If you want something directly comparable to the 12" Powerbook, the Fujitsu P5000 is the same price and the same weight. And the Fujitsu P2000 is actually smaller, lighter, and cheaper than the 12" Powerbook (although has somewhat fewer features).
Exactly what is so "proprietary" about Mac OS X that is scaring you away?
Well, the audio and video APIs, for example, which are still based on Cocoa and are a pain to use. And the Mac doesn't use an X11 desktop, it only runs X11 apps under Aqua, so X11 apps don't have good desktop integration. And OS X graphics isn't exactly fast. And on and on.
Overall, I have found that OS X is usable as a sort-of UNIX laptop, but less than ideal. Get one if you need to run OS X apps. If all applications you want to run are Linux/UNIX apps, an x86 laptop running Linux is cheaper, faster, and easier to install and maintain.
Interesting that Apple's notebooks (and mp3 player) are now the standard others are compared against.
I think that has more to do with the slow pace at which Apple rolls out new models than any kind of technical issues. As a result, every one of Apple's handful of laptops receives much more exposure and marketing dollars than any other model.
Don't get me wrong: the 12" Powerbook is pretty nice hardware, but there has been plenty of really nice hardware in the PC world as well. And the Sony beats thes 12" Powerbook hands-down in pretty much every area as far as I'm concerned.
Now you, too, can run an unaccelerated window system (Qt+DirectFB) that runs only a tiny fraction of the software that runs on X11, has much less functionality, and that requires you to pay big bucks to Troll Tech in order to develop commercial apps.
With brilliant ideas like that in the free software community, who needs enemies like Bill Gates trying to kill Linux on the desktop?
Problems with SCO's claim are well documented, and I cannot imagine that they intend to win this, but they have every right to issue a license for their own work (if it is) and it would mean exactly what they claim it would mean in that case.
[...]
It's not *your* distribution of it that is at question, it is *your vendor's* distribution to you. If that was not legit, then you cannot reasonably use the software.
Right. And my point is that if SCO can legitimately issue you a license on the code, then your vendor's (RedHat, etc.) distribution of Linux to you would not be legit under the GPL.
So, SCO can't really make money off this: they could theoretically keep you from using Linux if they had intellectual property rights, but a business model where RedHat distributes Linux and you need an SCO license to actually run it simply does not work under the GPL because RedHat cannot distribute Linux under those conditions.
Do you have any technical arguments left, or is all that remains innuendo?