Waves of popular but hopelessly tired or incorrect phrases and jokes occur regularly on Slashdot. They are largely done by unimaginative "me too" people who think they are imaginative. They can be called "karma whores", if you wish.
Examples:
- Can you imagine a Beowulf cluster of these - Lather, rinse, and repeat - Mastercard commercial spoofs (blahblah...priceless) - blahblah...CowboyNeal! - blahblah...Profit! - Haiku - Lord of the Rings poems - blahblah...begs the question...blahblah
One of my pet peeve phrases outside of Slashdot lately is "high rate of speed" when the speaker means "quickly". Acceleration is the rate at which velocity changes. Velocity is the rate at which position changes. So, what the hell is the rate of speed?
In my experience it's easier to backup and restore Linux based systems.
Do Linux distributions have the equivalent of Solaris' ufsdump tool (aside from things like dd or cpio)? ufsdump allows trivial backup and restore on a per-filesystem basis. Also it works over a network allowing a centralized backup server with a tape library.
If you are spending your own money, 1000 dollars will buy you a decently spec'ed second hand Ultra2 or Ultra60 on ebay which will give you a much better all round experience of Sun kit...
I absolutely agree with this. The 300MHz UltraSPARC II-based Ultra 30 and Ultra 60 workstations have similar overall performance (according to SPEC) to the Sun Blade 100. As an added bonus the Ultras have a genuine 40MB/sec SCSI controller (perfect for a two-disk array). The 24-bit Creator3D graphics for the Ultras is cheap now-a-days, too.
The only real advantage of the Blade 100 over the Ultras is maximum memory capacity. The Blade 150 is significantly better (650MHz USIIi instead of the 500MHz USIIe), but it starts at about $1300, which makes it less affordable.
I'm not sure I agree that the Blade 100 and Blade 150 give Sun a bad name, as they are decently organized and have very low power consumption. They are decent general-purpose workstations. I would guess, however, that the Blade 100's performance didn't live up to what people were expecting.
but I don't know of any individuals that use a Sun box themselves.
I do. I guess this makes your statement obselete? Sun boxes are very nice to work with (genuine firmware, well-laid-out cases), and SunPCi under Solaris allows "best of both worlds" operation (MS Windows in an X Window...just where it belongs).
Also, Sun hardware really isn't all that expensive. There is a very active secondary market for Sun hardware, which is a very good way to get your foot in the door for well under $1000 (or even less than $500). For the brand new UltraSPARC III systems, even they aren't expensive from the point of view of a company with a substantial IT infrastructure. Sun systems "Just Work" from the corporate point of view (like Macs "Just Work" from the desktop point of view).
Re:What desktop users want to know..
on
AMD's 64-bit Plot
·
· Score: 2
You can barely, oh so barely, tell the difference between 866MHz and 2.4GHZ, and only then when running certain high-end games or 3D modelling packages.
This is very true. I've been using Pentium-class PCs and UltraSPARC II machines for years. Recently, I got to try out a friend's 2GHz Pentium 4 Dell.
The result: the hard drive is so slow that it is essentially the limiting factor in the P4 system (it was a 7200RPM drive, too). For general use, I really don't see much practical difference among all the computers I use and the P4 system. I will admit that the P4 did very well with 3D games, and I'm sure things like Flash-based web pages will do well, too. Thankfully, I have a Playstation for games and don't care about Flash.
The need for faster CPUs and more memory can be determined only by an individual's true need. 3D modeling and scientific systems should get all the power available. General-purpose desktops maxed-out quite a long time ago.
This can be handled in well-written scripts. It isn't that big of a deal. For non-scripts (humans), 'man -k...' can narrow down the HP-UX df equivalent pretty quickly. Man pages make the platform differences much easier to deal with.
As for HP-UX's/etc structure, I really haven't worked with HP-UX. However, it couldn't be much worse than the differences between Slackware Linux and Red Hat Linux or between Solaris and OpenBSD. A few minutes of study is all that's needed to figure out many of the differences. The concepts are the same (hosts, netmasks, interface configs, resolver, etc.).
There is a subtle difference between "well written" and "well documented". UNIX is very well documented. Some or most of that documentation is well-written but not all. OpenBSD, perhaps, has the best written man pages I've seen, but even Solaris is largely good, too.
Do a 'man' on 'grep' or 'find' sometime and try to make anything out of that in 1 minute.
grep and find are two extremely powerful tools. The two together make for very brief scripts that scan and process whole filesystems. Add sed or awk to the mix, and a solid text processing system is born. It takes time, trial, and error, to extract the most benefit from these tools. Their man pages are really only a starting point.
One simple way to help a lot of people out is to not have engineers write the documents as if another engineer is the audience.
I've found when non-engineers write technical documents or when the audience is made too general, the documents become inaccurate as details are lost and different vocabularies creep in. Technical writing is extremely difficult, and it is often impossible to reach general audiences without losing the essential substance of the discussion. This doesn't mean the author is arrogant; rather, it means our world is so varied and each niche is so complex, that specialized audiences are inevitable.
Not really. There are many proprietary implementations of UNIX, but they abide by standards. This is why a "UNIX administrator" can feel comfortable on Solaris, IRIX, HPUX, Linux, BSD etc. It is also why software written under one UNIX is generally easy to get working on another UNIX.
Compared to Windows, UNIX is wide open. They are before my time, but I would guess that UNIX compares favorably to Mainframe OSes, too.
I've just look at a ps -ef on my Octane and there are at least half a dozen daemons running that I'd have to look at the docs to work out what they were...
However, on that Octane, a simple `man ` would probably answer most of your questions. Where is the non-Internet-base on-line documentation for everything in the Windows Task Manager.
One of the reasons for UNIX's transparency is the fact that UNIX is extremely well documented. Many people who are knowledgeable about UNIX are almost entirely self-tought using the documentation bundled with the OS. For example, I got a UNIX sysadmin certification using only the bundled documentation--nothing else.
Why can't IE run in a procesWhy can't IE run in a process with reduced privaliges?s with reduced privaliges?
Does Windows (any shade or flavor) have the ability to run a process under something equivalent to UNIX `su`? I do this with Mozilla on Linux/UNIX using an account that has very limited filesystem permissions.
If Sun bought Red Hat one half of the company would implode.
Not if Sun is smart about it. Buying Red Hat but leaving Red Hat's organization alone would be smart. Red Hat remains a separate OS company providing a well-known distribution and support services. Sun can continue by deriving the Sun Linux distribution from Red Hat's for the Sun LX50 et. al.
What Sun can offer Red Hat is even stronger corporate recognition and marketing. Red Hat can offer Sun a good piece of the Linux market pie. It's win-win.
I vote for any text editor that defaults to rendering HTML as a web page rather than just displaying the damn text. All I want is the damn text! That is what text editors are for!
This sort of feature-creep make some Linux tools extremely annoying. Some people may gasp at this, but I find Solaris' vi very refreshing after working with some of the vi clones out there.
Technical solutions to social problems will never succeed.
Legal solutions aren't necessarily the solution either. Think about zero-tolerance policies at schools (absurdly naive), drug laws (who do they protect, really), personal and corporate welfare by tax credit/deduction (misguided and unnecessarily complex), RIAA royalty per blank media (make the innocent pay), and so on.
DRM laws will simply be some combination of zero-tolerance policies, gun laws, and drug laws, in effect. The outcome is certainly not to our benefit, and a whole generation of really cool stuff will be wiped out to make paranoid media companies more comfy in their money-stuffed chairs. It really makes me cringe when I think about it.
We're talking about how some parts of your business become cash cows and support other parts of your business that they believe are worth investing in and will one day become profitable.
On a certain scale, this is fine. However, what Microsoft does is invest (very often at a loss) in nearly every technology-oriented market from cell phones to media centers to handheld tablets to office servers to enterprise databases. They put their tenticles into everything hoping for a few of them to catch hold. It sounds a lot like SPAM, but in a corporate marketing context. With tens of billions of dollars in reserve cash, a few dozen failed projects is pocket change to them.
Perhaps you can find an older version that runs on Solaris? I used Photoshop on Solaris a few years ago. People here will whine when I say this: Solaris, especially 8 and 9, makes a fine desktop OS. It's robust as hell and extremely well documented. Buy a used Sun on EBay or through mail order and be happy.
You're forgiving Microsoft for not supporting Motif in what they call Windows...
Well, that wasn't my intention. If I recall correctly, Motif is an industry standard, but the industry in this case were the commerical UNIX vendors. I wonder if Microsoft was even invited? Regardless, I doubt that Microsoft would have found implementing Motif worthwhile, because it would divert resources from their own efforts to produce the very robust and thoughtfully-done Windows toolkits (note sarcasm).
No. I was serious. Text editors that write to the file something other than the author intended are simply bad text editors. A tab is a tab, and a space is a space. Also, true tabbed indention is more text-editor agnositic and makes code more maintainable when it is worked on by more than one 2-space-tab 4-space-tab or 8-space-tab zealots. Spaces in place of tabs sucks. Make is just fine.
These are almost always trivial relative to the developers' wages and the project management overhead. A thousand dollars or whatever for Qt, for example, or even ten or twenty thousand dollars for a portable 3D kernel, will be worth it when people start thinking differently in the future. Business requirements change, and the software should be able to change with them. The only applications that themselves are cheaper than the licensing are trivial one-day apps that meet what is sometimes a short-sighted immediate need.
If performance is a requirement for the software, extra abstraction layers just get in the way.
Then optimize the 1% to 5% of code that performs inadequately. This takes much less time than migrating a whole code base to a new operating system API.
For example, if your program needs to clean up on forcible termination, a portable API probably isn't going to solve this on Windows because the app doesn't receive a signal; it just gets killed.
I don't see any option fixing this, unless separate processes keep watch on eachother. This sort of stuff can be partitioned off into a module called "Platform-specific Module". It will be a very small part of the application.
New applications will be written in Motif if the spec says they are written in Motif.
Who wrote that spec? That person is either tied to a legacy code base (a legitimate cause) or is living in the distant past. I don't see any good reason to keep Motif around for new applications.
There is the little problem about tabs and spaces being rendered identically by most software but meaning very different things to make.
This really isn't a big deal at all. If you have spaces instead of tabs, Make fails in a consistent manner. Big deal. Just don't use text editors that insist on expanding tabs into spaces; those text editors are the problem, not Make.
But try and move a makefile for a complex build from Unix to Windows and see how well it works.
It can work very well. MKS and others provide a good make program and many of the supporting UNIX tools for Windows. Putting platform-dependent shell scripts in front of make encapsulates differences and makes supporting multiple platforms no more or less difficult than with Ant (the platform differences remain no matter the build tool you use). Also, using the non-standard GNU make extensions is simply not a good idea in any context, unless you can guarantee GNU make is installed in every context. Sticking to POSIX is much easier in the long run.
What would really be better than Ant, is a Java implementation of the MKS toolkit or something similar.
Ant works pretty much the same across different operating systems...
As long as you deal with the Windows and UNIX pathnames well. Mixing Windows-based developers and UNIX-based developers in a project that uses Ant can still be a PITA if not thought out.
Make is super-powerful but infuriatingly incompatible even across different versions of the same product, such as GNU make.
It isn't difficult to write POSIX-compliant makefiles that work pretty much anywhere. Front-ending the makefiles with a shell script can encapsulate all the platform-specific stuff, such as command line options and the compiler to use. Again, it really is not difficult.
Ant is easy to learn, after a brief period of warping your brain into their XML way of thinking, executes smoothly and quickly, and is infinitely extensible and very Java-friendly.
The Java-centricity of Ant is its biggest weakness. Having to learn Ant for Java and make for everything else is just not good. I just use make for everything and my life is simpler for it.
It really isn't an equivalent replacement. Although it is potentially more widely deployable than make, make is still much more powerful, because the/usr/bin/* tools are implicitly part of make's functionality. Having full control over I/O redirection thanks to a true UNIX shell environment is pretty handy, too.
Also, make is much more appropriate for offices that do development using more than one programming language (C, C++, Java, Lisp, etc.). It seems Ant is really a tool for Java developers (even though it is possible to kludge Ant's XML files for non-Java projects, I think it would get pretty ugly pretty fast).
And he's right, the only way to avoid massive layers of backwards-compatible cruft is to just slough off the existing infrastructure and create the OS anew for every release.
True. However, if the userland apps are written properly using a sufficiently high-level language, even C, and using standards-based and/or portable APIs, then kernel changes should break only the invervening abstraction layers. Download the updated API or whatever (not much effort), and the huge amount of effort that went in to the userland app is preserved.
This is why I feel so sorry for people who write applications using Windows-only or UNIX-only or whatever-only APIs, when there are portable ways of doing things. Taking standards documents and black-lining the parts that aren't implemented on all the target platforms (thus achieving the lowest-common-denominator) goes a long way towards producing an application that will tolerate volatility at the operating system level. And, really, it isn't much effort for an important piece of software (and a week or two sifting through documentation will only improve the end product, trust me).
And guess what: even the lowest-common-denominator is usually very useful and sufficient to meet the requirements for the software. People who whine otherwise are usually the eye-candy babies who demand using all the nifty Internet Explorer extensions to make dancing mouse trailers and other garbage (for example).
The only excusable applications are those written before truly portable APIs came around. For example, old UNIX apps written with Motif should be forgiven, because Qt, Java Swing, and other fairly recent APIs weren't available. But new applications? No excuse at all.
Slashdot Mirror
Waves of popular but hopelessly tired or incorrect phrases and jokes occur regularly on Slashdot. They are largely done by unimaginative "me too" people who think they are imaginative. They can be called "karma whores", if you wish.
Examples:
- Can you imagine a Beowulf cluster of these
- Lather, rinse, and repeat
- Mastercard commercial spoofs (blahblah...priceless)
- blahblah...CowboyNeal!
- blahblah...Profit!
- Haiku
- Lord of the Rings poems
- blahblah...begs the question...blahblah
One of my pet peeve phrases outside of Slashdot lately is "high rate of speed" when the speaker means "quickly". Acceleration is the rate at which velocity changes. Velocity is the rate at which position changes. So, what the hell is the rate of speed?
In my experience it's easier to backup and restore Linux based systems.
Do Linux distributions have the equivalent of Solaris' ufsdump tool (aside from things like dd or cpio)? ufsdump allows trivial backup and restore on a per-filesystem basis. Also it works over a network allowing a centralized backup server with a tape library.
If you are spending your own money, 1000 dollars will buy you a decently spec'ed second hand Ultra2 or Ultra60 on ebay which will give you a much better all round experience of Sun kit...
I absolutely agree with this. The 300MHz UltraSPARC II-based Ultra 30 and Ultra 60 workstations have similar overall performance (according to SPEC) to the Sun Blade 100. As an added bonus the Ultras have a genuine 40MB/sec SCSI controller (perfect for a two-disk array). The 24-bit Creator3D graphics for the Ultras is cheap now-a-days, too.
The only real advantage of the Blade 100 over the Ultras is maximum memory capacity. The Blade 150 is significantly better (650MHz USIIi instead of the 500MHz USIIe), but it starts at about $1300, which makes it less affordable.
I'm not sure I agree that the Blade 100 and Blade 150 give Sun a bad name, as they are decently organized and have very low power consumption. They are decent general-purpose workstations. I would guess, however, that the Blade 100's performance didn't live up to what people were expecting.
but I don't know of any individuals that use a Sun box themselves.
I do. I guess this makes your statement obselete? Sun boxes are very nice to work with (genuine firmware, well-laid-out cases), and SunPCi under Solaris allows "best of both worlds" operation (MS Windows in an X Window...just where it belongs).
Also, Sun hardware really isn't all that expensive. There is a very active secondary market for Sun hardware, which is a very good way to get your foot in the door for well under $1000 (or even less than $500). For the brand new UltraSPARC III systems, even they aren't expensive from the point of view of a company with a substantial IT infrastructure. Sun systems "Just Work" from the corporate point of view (like Macs "Just Work" from the desktop point of view).
You can barely, oh so barely, tell the difference between 866MHz and 2.4GHZ, and only then when running certain high-end games or 3D modelling packages.
This is very true. I've been using Pentium-class PCs and UltraSPARC II machines for years. Recently, I got to try out a friend's 2GHz Pentium 4 Dell.
The result: the hard drive is so slow that it is essentially the limiting factor in the P4 system (it was a 7200RPM drive, too). For general use, I really don't see much practical difference among all the computers I use and the P4 system. I will admit that the P4 did very well with 3D games, and I'm sure things like Flash-based web pages will do well, too. Thankfully, I have a Playstation for games and don't care about Flash.
The need for faster CPUs and more memory can be determined only by an individual's true need. 3D modeling and scientific systems should get all the power available. General-purpose desktops maxed-out quite a long time ago.
Solaris: df -k
...' can narrow down the HP-UX df equivalent pretty quickly. Man pages make the platform differences much easier to deal with.
/etc structure, I really haven't worked with HP-UX. However, it couldn't be much worse than the differences between Slackware Linux and Red Hat Linux or between Solaris and OpenBSD. A few minutes of study is all that's needed to figure out many of the differences. The concepts are the same (hosts, netmasks, interface configs, resolver, etc.).
HP-UX: bdf -k
This can be handled in well-written scripts. It isn't that big of a deal. For non-scripts (humans), 'man -k
As for HP-UX's
"Extremely well written" is very subjective.
There is a subtle difference between "well written" and "well documented". UNIX is very well documented. Some or most of that documentation is well-written but not all. OpenBSD, perhaps, has the best written man pages I've seen, but even Solaris is largely good, too.
Do a 'man' on 'grep' or 'find' sometime and try to make anything out of that in 1 minute.
grep and find are two extremely powerful tools. The two together make for very brief scripts that scan and process whole filesystems. Add sed or awk to the mix, and a solid text processing system is born. It takes time, trial, and error, to extract the most benefit from these tools. Their man pages are really only a starting point.
One simple way to help a lot of people out is to not have engineers write the documents as if another engineer is the audience.
I've found when non-engineers write technical documents or when the audience is made too general, the documents become inaccurate as details are lost and different vocabularies creep in. Technical writing is extremely difficult, and it is often impossible to reach general audiences without losing the essential substance of the discussion. This doesn't mean the author is arrogant; rather, it means our world is so varied and each niche is so complex, that specialized audiences are inevitable.
Err..umm..UNIX is a proprietary OS.
Not really. There are many proprietary implementations of UNIX, but they abide by standards. This is why a "UNIX administrator" can feel comfortable on Solaris, IRIX, HPUX, Linux, BSD etc. It is also why software written under one UNIX is generally easy to get working on another UNIX.
Compared to Windows, UNIX is wide open. They are before my time, but I would guess that UNIX compares favorably to Mainframe OSes, too.
I've just look at a ps -ef on my Octane and there are at least half a dozen daemons running that I'd have to look at the docs to work out what they were...
However, on that Octane, a simple `man ` would probably answer most of your questions. Where is the non-Internet-base on-line documentation for everything in the Windows Task Manager.
One of the reasons for UNIX's transparency is the fact that UNIX is extremely well documented. Many people who are knowledgeable about UNIX are almost entirely self-tought using the documentation bundled with the OS. For example, I got a UNIX sysadmin certification using only the bundled documentation--nothing else.
Why can't IE run in a procesWhy can't IE run in a process with reduced privaliges?s with reduced privaliges?
Does Windows (any shade or flavor) have the ability to run a process under something equivalent to UNIX `su`? I do this with Mozilla on Linux/UNIX using an account that has very limited filesystem permissions.
Things time-out all the time and it disconnects if a bird lands on the dish.
Would that bird be a "leaky abstraction"?
If Sun bought Red Hat one half of the company would implode.
Not if Sun is smart about it. Buying Red Hat but leaving Red Hat's organization alone would be smart. Red Hat remains a separate OS company providing a well-known distribution and support services. Sun can continue by deriving the Sun Linux distribution from Red Hat's for the Sun LX50 et. al.
What Sun can offer Red Hat is even stronger corporate recognition and marketing. Red Hat can offer Sun a good piece of the Linux market pie. It's win-win.
OK, so what editor should we kill?
I vote for any text editor that defaults to rendering HTML as a web page rather than just displaying the damn text. All I want is the damn text! That is what text editors are for!
This sort of feature-creep make some Linux tools extremely annoying. Some people may gasp at this, but I find Solaris' vi very refreshing after working with some of the vi clones out there.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
What is sad is that there are many people who take their liberty for granted and won't realize what they are giving up until it is too late.
Technical solutions to social problems will never succeed.
Legal solutions aren't necessarily the solution either. Think about zero-tolerance policies at schools (absurdly naive), drug laws (who do they protect, really), personal and corporate welfare by tax credit/deduction (misguided and unnecessarily complex), RIAA royalty per blank media (make the innocent pay), and so on.
DRM laws will simply be some combination of zero-tolerance policies, gun laws, and drug laws, in effect. The outcome is certainly not to our benefit, and a whole generation of really cool stuff will be wiped out to make paranoid media companies more comfy in their money-stuffed chairs. It really makes me cringe when I think about it.
We're talking about how some parts of your business become cash cows and support other parts of your business that they believe are worth investing in and will one day become profitable.
On a certain scale, this is fine. However, what Microsoft does is invest (very often at a loss) in nearly every technology-oriented market from cell phones to media centers to handheld tablets to office servers to enterprise databases. They put their tenticles into everything hoping for a few of them to catch hold. It sounds a lot like SPAM, but in a corporate marketing context. With tens of billions of dollars in reserve cash, a few dozen failed projects is pocket change to them.
Adobe Photoshop
Perhaps you can find an older version that runs on Solaris? I used Photoshop on Solaris a few years ago. People here will whine when I say this: Solaris, especially 8 and 9, makes a fine desktop OS. It's robust as hell and extremely well documented. Buy a used Sun on EBay or through mail order and be happy.
You're forgiving Microsoft for not supporting Motif in what they call Windows...
Well, that wasn't my intention. If I recall correctly, Motif is an industry standard, but the industry in this case were the commerical UNIX vendors. I wonder if Microsoft was even invited? Regardless, I doubt that Microsoft would have found implementing Motif worthwhile, because it would divert resources from their own efforts to produce the very robust and thoughtfully-done Windows toolkits (note sarcasm).
repeat after me: Make sucks.
No. I was serious. Text editors that write to the file something other than the author intended are simply bad text editors. A tab is a tab, and a space is a space. Also, true tabbed indention is more text-editor agnositic and makes code more maintainable when it is worked on by more than one 2-space-tab 4-space-tab or 8-space-tab zealots. Spaces in place of tabs sucks. Make is just fine.
licensing fees
These are almost always trivial relative to the developers' wages and the project management overhead. A thousand dollars or whatever for Qt, for example, or even ten or twenty thousand dollars for a portable 3D kernel, will be worth it when people start thinking differently in the future. Business requirements change, and the software should be able to change with them. The only applications that themselves are cheaper than the licensing are trivial one-day apps that meet what is sometimes a short-sighted immediate need.
If performance is a requirement for the software, extra abstraction layers just get in the way.
Then optimize the 1% to 5% of code that performs inadequately. This takes much less time than migrating a whole code base to a new operating system API.
For example, if your program needs to clean up on forcible termination, a portable API probably isn't going to solve this on Windows because the app doesn't receive a signal; it just gets killed.
I don't see any option fixing this, unless separate processes keep watch on eachother. This sort of stuff can be partitioned off into a module called "Platform-specific Module". It will be a very small part of the application.
New applications will be written in Motif if the spec says they are written in Motif.
Who wrote that spec? That person is either tied to a legacy code base (a legitimate cause) or is living in the distant past. I don't see any good reason to keep Motif around for new applications.
There is the little problem about tabs and spaces being rendered identically by most software but meaning very different things to make.
This really isn't a big deal at all. If you have spaces instead of tabs, Make fails in a consistent manner. Big deal. Just don't use text editors that insist on expanding tabs into spaces; those text editors are the problem, not Make.
But try and move a makefile for a complex build from Unix to Windows and see how well it works.
It can work very well. MKS and others provide a good make program and many of the supporting UNIX tools for Windows. Putting platform-dependent shell scripts in front of make encapsulates differences and makes supporting multiple platforms no more or less difficult than with Ant (the platform differences remain no matter the build tool you use). Also, using the non-standard GNU make extensions is simply not a good idea in any context, unless you can guarantee GNU make is installed in every context. Sticking to POSIX is much easier in the long run.
What would really be better than Ant, is a Java implementation of the MKS toolkit or something similar.
Ant works pretty much the same across different operating systems...
As long as you deal with the Windows and UNIX pathnames well. Mixing Windows-based developers and UNIX-based developers in a project that uses Ant can still be a PITA if not thought out.
Make is super-powerful but infuriatingly incompatible even across different versions of the same product, such as GNU make.
It isn't difficult to write POSIX-compliant makefiles that work pretty much anywhere. Front-ending the makefiles with a shell script can encapsulate all the platform-specific stuff, such as command line options and the compiler to use. Again, it really is not difficult.
Ant is easy to learn, after a brief period of warping your brain into their XML way of thinking, executes smoothly and quickly, and is infinitely extensible and very Java-friendly.
The Java-centricity of Ant is its biggest weakness. Having to learn Ant for Java and make for everything else is just not good. I just use make for everything and my life is simpler for it.
Ant is the Java equivalent of make and makefiles.
/usr/bin/* tools are implicitly part of make's functionality. Having full control over I/O redirection thanks to a true UNIX shell environment is pretty handy, too.
It really isn't an equivalent replacement. Although it is potentially more widely deployable than make, make is still much more powerful, because the
Also, make is much more appropriate for offices that do development using more than one programming language (C, C++, Java, Lisp, etc.). It seems Ant is really a tool for Java developers (even though it is possible to kludge Ant's XML files for non-Java projects, I think it would get pretty ugly pretty fast).
And he's right, the only way to avoid massive layers of backwards-compatible cruft is to just slough off the existing infrastructure and create the OS anew for every release.
True. However, if the userland apps are written properly using a sufficiently high-level language, even C, and using standards-based and/or portable APIs, then kernel changes should break only the invervening abstraction layers. Download the updated API or whatever (not much effort), and the huge amount of effort that went in to the userland app is preserved.
This is why I feel so sorry for people who write applications using Windows-only or UNIX-only or whatever-only APIs, when there are portable ways of doing things. Taking standards documents and black-lining the parts that aren't implemented on all the target platforms (thus achieving the lowest-common-denominator) goes a long way towards producing an application that will tolerate volatility at the operating system level. And, really, it isn't much effort for an important piece of software (and a week or two sifting through documentation will only improve the end product, trust me).
And guess what: even the lowest-common-denominator is usually very useful and sufficient to meet the requirements for the software. People who whine otherwise are usually the eye-candy babies who demand using all the nifty Internet Explorer extensions to make dancing mouse trailers and other garbage (for example).
The only excusable applications are those written before truly portable APIs came around. For example, old UNIX apps written with Motif should be forgiven, because Qt, Java Swing, and other fairly recent APIs weren't available. But new applications? No excuse at all.