Wow, flashback to 1995, when *I* transitioned from tcsh to bash. I had grown up on older Sun boxen where csh/tcsh was the prefered shell, but as I started using other Unices like Linux and AIX and as I started writing more shell scripts (especially little one-off scripts in interactive sessions), I decided to make the jump to bash.
All in all, bash is a better shell, especially for scripting. Back then tcsh was more configurable and usable, but by now I think tcsh has fallen behind. Anyway, there is a one-to-one mapping between most tcsh and bash features. The only diffence is the syntax: export X=Y instead of setenv X Y, alias foo="bar" instead of alias foo "bar".
When I switched, the two things I missed the most were tcsh's programmable completion, which is only matched by bash in version 2, and the method of doing a reverse search of the command history (tcsh's esc-p vs. bash's esc-r).
You take a big risk if you agree to a fixed price contract. While it might seem like there is potential to make more by working efficiently, it doesn't usually happen that way. Estimating how much time a software project will take is *hard*, much harder than it seems. Even if you have experience making those kinds of estimates you are likely to be significantly wrong -- usually too short. Then there is the question of whether a feature is actually done. Particularly if there isn't a well documented requirements document, there can be a wide gap in expectations.
So you can chop the project into tiny, easy-to-estimate pieces and write up a huge requirements document to manage your own risk, or you can just take an hourly rate and code. I know which I'd rather do...
That is, that key combo cannot be intercepted by applications thus making it impossible to create infamous fake logins for grabbing user credentials mere looks-like-login-screen
This is actually untrue. There are several ways to capture ctrl-alt-del in Windows. One is by remapping the keyboard with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Keyboard Layout registry entry. This changes the key mappings before the system processes ctrl-alt-del.
The idea of a secure access key is a good one, but MS has a broken implementation since they allow it to be circumvented.
I can't think of any others based on the 8008. It just barely enough processor to do anything; I think it was targeted as a calculator processor, not a general purpose CPU. The 8080, which ran the original Altair, was a better all around chip which found itself in most of the early micros, followed by the 6800 (Motorola), 6502 (MOS), Z80 (Zilog, source and mostly binary compatible with the 8080, but twice as many registers and an expanded instruction set), and eventually the 8088 that IBM used.
I'm a little curious how the key is shared between the keyboard and the computer?
There is no need for a cable to securely transmit the key. You can do a secure key exchange on an unsecured channel just fine with asymmetric encryption. The RSA way is to generate a key pair on side A, send the public key over to B, who encrypts the symmetric key (which can be randomly generated) with the A's public key and sends it back to A who decrypts it with his private key. The Diffie-Hellman algorithm works in a similar fashion.
As far as I know, both 802.11 and Bluetooth use some variation of that to do a key exchange at the start of a session.
Microsoft doesn't use it for its own products. If.NET is so good, why? If someone said, "I would never eat this, but here is some for you", would you take what was offered?
Thats a bit unfair. MS has been developing its Windows applications in native C/C++ for over 10 years. They obviously have significant infrastructure based on these technologies that isn't going away overnight. To expect them to release.NET (the platform, not the marketing propaganda) versions of Office, SQL Server or IE in such a short timeframe is ridiculous.
You can bet that any new apps developed by MS in the last couple of years are.NET. The others will be ported over in a long process over years or even decades. My guess is we will probably see their most security-critical apps ported over first: IIS and Outlook.
Programs written in.NET are more easily decompiled. If you discover and implement an especially good algorithm, others may be able to see what you did. Maybe that is the reason for number 1, above.
Same with Java, and even C/C++ to a lesser extent. There is no such thing as a secure program that runs locally without hardware support.
All the tools are proprietary.
VC++ and VB are proprietary too. At least there is Mono...
My understanding is that the license agreement for.NET prevents a company from using.NET to compete with Microsoft in some areas.
As do the agreements for VC++ and their pre-.NET development tools. While these may indeed be major issues, I don't think they are significantly worse for.NET over their previous development environment.
Do you want your company to be tied to the fortunes of Microsoft? If you trust Microsoft to do the right thing for you and your company, then use Microsoft's proprietary tools.
This is a legitmate question. But it is not any worse than MS specific development pre-.NET: before: choice of MS proprietary language (VB) or quasi-standard (VC++) targeting MS specific APIs. With.NET: choice of MS proprietary language (VB, C#) or quasi-standard (Managed C++) targeting MS specific runtime enviroment.
TurboVision
on
GTK+ TTY Port
·
· Score: 3, Interesting
It was called TurboVision. A user-maintained fork still exists and has been ported to various platforms and compilers including gcc and Linux.
Its key difference from the text-based GTK+ is that it was a text-based library only. There was no graphical implementation of the same API.
Since it runs on an 8088, it must use the x86 "real" mode, instead of protected mode. Which means that only 1MB of memory is addressable, so the gig of RAM is irrelevent. Contiki would only use the first 1MB.
If they want to get a new browser, they will be forced to make a choice between upgrading Windows and installing mozilla or another non-MS browser.
MS wants to force this choice, because they expect many to choose the upgrade. If upgrading involves getting a new PC, so be it; MS gets their money either way.
MS just isn't offering IE as a free standalone download. No doubt it's to escape legal backfire from their declaration that it's an integral part of the OS (if it really is - then you can't offer a free download as they do.)
I'd argue MS is stopping the standalone version because IE because it is now unthreatened. As we can see, even though there have been no major improvements in IE in a long, long time, it still holds over 90% of the market. By inertia, they have a solid position that will last a long time. MS has accomplished its strategic goal of taking over the browser market.
So, with that accomplished, why develop a product and give it away? MS has to sell the next version of Windows and it must provide new features over Win2k/XP/etc to make upgrading worthwhile. If a standalone browser makes new features available to customers who don't upgrade, then they've made their job harder.
Expect a standalone IE in the future only if Mozilla/Opera/etc. grab some serious market share.
don't expect this to be ported on Mono asap, Mono still lacks a Managed C++ compiler
But the compiled MSIL should run on Mono -- at least if Mono has developed all the class libraries Quake II depends on. So while Mono may not be able to compile it, it should, some day, be able to run it.
Re:These arguments are so tired
on
Analysis: x86 Vs PPC
·
· Score: 2, Insightful
software IS the more important aspect
Yes, and software is becoming more and more portable.
As the article observes, Linux (and open-source software in general) is not locked into the x86 architecture like Windows is. The use of server-side Java is growing, also architecture agnostic. Additionally, the web and web-based applications have shifted much of the work custom client applications used to do into the browser. Once again, architecture is doesn't matter.
The trend is that CPU architecture as a means of lock-in is declining, due those factors and many others. At some point, the cost of moving to another architecture will decline to near-zero, and the CPU business will shift to more of a commodity market, where people will buy on merit alone.
The only question is when it will happen; people have been predicting it for years (remember when NT ran on PPC, MIPS and Alpha?).
Right now, the PPC seems to win in some areas (power consumption, die size) and, barring architectural lock-in, it would probably take a large chunk of the Intel/AMD market.
"don't apply for a job here if you took the course"
If thats their attitude, you probably don't want to work there anyways. I can't imagine what they expect you to do; build a virus at work and unleash it on the workplace? Thats a simple question of ethics.
When using non-generic containers in Java, you are usually forced to make a cast when accessing its members. For example:
String s = (String) list.get(0);
It gets worse if you are making multiple calls, because you usually need parentheses to bind the cast:
String s = ((Foo) list.get(0)).fooMethod();
However, with generics, you don't have to write the cast, because the type is implied. The bytecode is the same, but the code is much clearer:
String s = list.get(0).fooMethod();
Tell me how that is less readable. Anybody who thinks generics are unreadable is probably thinking of the worst C++ template abuses, needless complexity, and obscure syntax. Thankfully, Java generics are simple and clear.
Berlin is the captial. Before reunification, Berlin was the the capital in the east, and Bonn was the capital in the west. Munich has never been the capital of Germany, although it is the provincial capital of Bavaria.
...and a key advantage of the Euro for blackmarket transactions is that the highest denomination is 500, instead of 100 for US bills. Which means approximately five times fewer bills for large transactions. I've heard the US is considering introducing the 1000 dollar bill into general circulation to compete.
I took CPSC 510, the compiler course, with Aycock around 1996. He was definately one of the better lecturers I had; I suspect it won't be a lightweight treatment of the subject either. He has also done some work on the Linux kernel (one of the Adaptec SCSI drivers, I believe). I'd say this is likely to be a really interesting, worthwhile course. I miss school...
Java is not always slower. Java's interpreted nature is generally seen as a weakness, but it has advantages too. For example, the JIT has profiling data immediately at hand when doing optimization, whereas compiled languages won't. Even in cases where compiled languages do use profile feedback, it may not be representative of the current program usage.
Try writing a simple recursive Fibonacci number calculator in both C++ and Java. The Java one is faster, when using a JIT enabled JVM. Of course, that is a contrived example, but it shows that just-in-time compiling can be faster.
Also false. Ext2fs uses has a one second granularity, like most traditional Unix filesystems. This is easily demostratable with "ls -l -time-style=full-iso". While this is still a fairly coarse measurement, I've never seen a problem in practice.
Re:this is all well and good
on
GCC 3.3 Released
·
· Score: 2, Informative
The GNU make has this bug even worse, since it only checks file size most of the time.
False. GNU make checks the last file modification time. If you have any problems getting consistant incremental builds, it is probably because the Makefile has incorrect dependency information. For example, if a header file changes the size of a struct, every source file that includes it should be recompiled. An automated tool like "gcc -MM" is the best way to ensure the dependencies are correct.
Your example is a bad one. Microsoft did its best to avoid starting over with its operating systems. And when it did, it did so very carefully with as much backwards compability as possible.
Windows will still run MS-DOS binaries and Windows 1.0 through Windows ME all ran atop the MS-DOS code base in one way or another. They started over exactly once, when they build NT. And they gave it over 7 years to mature before they dumped the old MS-DOS/Windows code. And even with this one example, they ensured it was as compatible as possible to the old, which is why almost any program written for Windows 95 (and many written for earlier OSs, too) will still work with XP, 7+ years later.
Operating systems are a particularly good analogy, too because, like e-mail, it is a critical piece of infrastructure that depends heavily on interoperating with what else is out there.
Another reason for the x.99 to x.95 shift is for more practical reasons. Bricks and mortar retail outlets simply want to reduce the usage of pennies. Management of cash is still an issue for businesses, and if they can reduce their reliance on bulky pennies for the cost of four cents a sale, it is sometimes worth it, particularly if they deal in high volumes. (Even so, since pennies are still legal tender, they can't ignore them completely.)
Of course, that reason is completely irrelevent to internet sales, so I would predict less x.95's than in the real world.
The problem with curl or wget is that they handle only the most simple transmission problems. They can resume a file that got cut off before the end.
Rsync can handle any form of corruption: even the file somehow gets bad bits in the middle of it, you can just rerun rsync and it finds the corrupt sections and fixes it up.
Of course, newer P2P apps like BitTorrent are just as good as rsync at fixing corrupted files, but with the additional advantage of being able to download from multiple peers at once. Rsync definately has its place, but for ISOs, BitTorrent is the best I've seen yet.
If they do release RH9, it would be nice if they would release 8.1 at the same time. Even if its just RH8 with all the errata and security updates, it would be nice to have a solid distribution I can install from CD and not have to download 100's of megabytes in patches post install.
Slashdot Mirror
Wow, flashback to 1995, when *I* transitioned from tcsh to bash. I had grown up on older Sun boxen where csh/tcsh was the prefered shell, but as I started using other Unices like Linux and AIX and as I started writing more shell scripts (especially little one-off scripts in interactive sessions), I decided to make the jump to bash.
All in all, bash is a better shell, especially for scripting. Back then tcsh was more configurable and usable, but by now I think tcsh has fallen behind. Anyway, there is a one-to-one mapping between most tcsh and bash features. The only diffence is the syntax: export X=Y instead of setenv X Y, alias foo="bar" instead of alias foo "bar".
When I switched, the two things I missed the most were tcsh's programmable completion, which is only matched by bash in version 2, and the method of doing a reverse search of the command history (tcsh's esc-p vs. bash's esc-r).
There are lots of great sites on getting the most from bash; here are a few good starting points:
ftp://ftp.cwru.edu/pub/bash/FAQ
http://www.caliban.org/bash/index.shtml
http://www.deadman.org/bash.html
You take a big risk if you agree to a fixed price contract. While it might seem like there is potential to make more by working efficiently, it doesn't usually happen that way. Estimating how much time a software project will take is *hard*, much harder than it seems. Even if you have experience making those kinds of estimates you are likely to be significantly wrong -- usually too short. Then there is the question of whether a feature is actually done. Particularly if there isn't a well documented requirements document, there can be a wide gap in expectations.
So you can chop the project into tiny, easy-to-estimate pieces and write up a huge requirements document to manage your own risk, or you can just take an hourly rate and code. I know which I'd rather do...
That is, that key combo cannot be intercepted by applications thus making it impossible to create infamous fake logins for grabbing user credentials mere looks-like-login-screen
o l\Keyboard Layout registry entry. This changes the key mappings before the system processes ctrl-alt-del.
This is actually untrue. There are several ways to capture ctrl-alt-del in Windows. One is by remapping the keyboard with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr
The idea of a secure access key is a good one, but MS has a broken implementation since they allow it to be circumvented.
I can't think of any others based on the 8008. It just barely enough processor to do anything; I think it was targeted as a calculator processor, not a general purpose CPU. The 8080, which ran the original Altair, was a better all around chip which found itself in most of the early micros, followed by the 6800 (Motorola), 6502 (MOS), Z80 (Zilog, source and mostly binary compatible with the 8080, but twice as many registers and an expanded instruction set), and eventually the 8088 that IBM used.
I'm a little curious how the key is shared between the keyboard and the computer?
There is no need for a cable to securely transmit the key. You can do a secure key exchange on an unsecured channel just fine with asymmetric encryption. The RSA way is to generate a key pair on side A, send the public key over to B, who encrypts the symmetric key (which can be randomly generated) with the A's public key and sends it back to A who decrypts it with his private key. The Diffie-Hellman algorithm works in a similar fashion.
As far as I know, both 802.11 and Bluetooth use some variation of that to do a key exchange at the start of a session.
Microsoft doesn't use it for its own products. If .NET is so good, why? If someone said, "I would never eat this, but here is some for you", would you take what was offered?
.NET (the platform, not the marketing propaganda) versions of Office, SQL Server or IE in such a short timeframe is ridiculous.
.NET. The others will be ported over in a long process over years or even decades. My guess is we will probably see their most security-critical apps ported over first: IIS and Outlook.
.NET are more easily decompiled. If you discover and implement an especially good algorithm, others may be able to see what you did. Maybe that is the reason for number 1, above.
.NET prevents a company from using .NET to compete with Microsoft in some areas.
.NET over their previous development environment.
.NET: choice of MS proprietary language (VB, C#) or quasi-standard (Managed C++) targeting MS specific runtime enviroment.
Thats a bit unfair. MS has been developing its Windows applications in native C/C++ for over 10 years. They obviously have significant infrastructure based on these technologies that isn't going away overnight. To expect them to release
You can bet that any new apps developed by MS in the last couple of years are
Programs written in
Same with Java, and even C/C++ to a lesser extent. There is no such thing as a secure program that runs locally without hardware support.
All the tools are proprietary.
VC++ and VB are proprietary too. At least there is Mono...
My understanding is that the license agreement for
As do the agreements for VC++ and their pre-.NET development tools. While these may indeed be major issues, I don't think they are significantly worse for
Do you want your company to be tied to the fortunes of Microsoft? If you trust Microsoft to do the right thing for you and your company, then use Microsoft's proprietary tools.
This is a legitmate question. But it is not any worse than MS specific development pre-.NET: before: choice of MS proprietary language (VB) or quasi-standard (VC++) targeting MS specific APIs. With
It was called TurboVision. A user-maintained fork still exists and has been ported to various platforms and compilers including gcc and Linux.
Its key difference from the text-based GTK+ is that it was a text-based library only. There was no graphical implementation of the same API.
Since it runs on an 8088, it must use the x86 "real" mode, instead of protected mode. Which means that only 1MB of memory is addressable, so the gig of RAM is irrelevent. Contiki would only use the first 1MB.
:)
I'm sure it would be plenty fast at 3ghz though
If they want to get a new browser, they will be forced to make a choice between upgrading Windows and installing mozilla or another non-MS browser.
MS wants to force this choice, because they expect many to choose the upgrade. If upgrading involves getting a new PC, so be it; MS gets their money either way.
MS just isn't offering IE as a free standalone download. No doubt it's to escape legal backfire from their declaration that it's an integral part of the OS (if it really is - then you can't offer a free download as they do.)
I'd argue MS is stopping the standalone version because IE because it is now unthreatened. As we can see, even though there have been no major improvements in IE in a long, long time, it still holds over 90% of the market. By inertia, they have a solid position that will last a long time. MS has accomplished its strategic goal of taking over the browser market.
So, with that accomplished, why develop a product and give it away? MS has to sell the next version of Windows and it must provide new features over Win2k/XP/etc to make upgrading worthwhile. If a standalone browser makes new features available to customers who don't upgrade, then they've made their job harder.
Expect a standalone IE in the future only if Mozilla/Opera/etc. grab some serious market share.
don't expect this to be ported on Mono asap, Mono still lacks a Managed C++ compiler
But the compiled MSIL should run on Mono -- at least if Mono has developed all the class libraries Quake II depends on. So while Mono may not be able to compile it, it should, some day, be able to run it.
software IS the more important aspect
Yes, and software is becoming more and more portable.
As the article observes, Linux (and open-source software in general) is not locked into the x86 architecture like Windows is. The use of server-side Java is growing, also architecture agnostic. Additionally, the web and web-based applications have shifted much of the work custom client applications used to do into the browser. Once again, architecture is doesn't matter.
The trend is that CPU architecture as a means of lock-in is declining, due those factors and many others. At some point, the cost of moving to another architecture will decline to near-zero, and the CPU business will shift to more of a commodity market, where people will buy on merit alone.
The only question is when it will happen; people have been predicting it for years (remember when NT ran on PPC, MIPS and Alpha?).
Right now, the PPC seems to win in some areas (power consumption, die size) and, barring architectural lock-in, it would probably take a large chunk of the Intel/AMD market.
"don't apply for a job here if you took the course"
If thats their attitude, you probably don't want to work there anyways. I can't imagine what they expect you to do; build a virus at work and unleash it on the workplace? Thats a simple question of ethics.
Huh? Generics make code more readable!
When using non-generic containers in Java, you are usually forced to make a cast when accessing its members. For example:
String s = (String) list.get(0);
It gets worse if you are making multiple calls, because you usually need parentheses to bind the cast:
String s = ((Foo) list.get(0)).fooMethod();
However, with generics, you don't have to write the cast, because the type is implied. The bytecode is the same, but the code is much clearer:
String s = list.get(0).fooMethod();
Tell me how that is less readable. Anybody who thinks generics are unreadable is probably thinking of the worst C++ template abuses, needless complexity, and obscure syntax. Thankfully, Java generics are simple and clear.
I believe, however, that Munich is the capital
Berlin is the captial. Before reunification, Berlin was the the capital in the east, and Bonn was the capital in the west. Munich has never been the capital of Germany, although it is the provincial capital of Bavaria.
...and a key advantage of the Euro for blackmarket transactions is that the highest denomination is 500, instead of 100 for US bills. Which means approximately five times fewer bills for large transactions. I've heard the US is considering introducing the 1000 dollar bill into general circulation to compete.
I took CPSC 510, the compiler course, with Aycock around 1996. He was definately one of the better lecturers I had; I suspect it won't be a lightweight treatment of the subject either. He has also done some work on the Linux kernel (one of the Adaptec SCSI drivers, I believe). I'd say this is likely to be a really interesting, worthwhile course. I miss school...
Java is not always slower. Java's interpreted nature is generally seen as a weakness, but it has advantages too. For example, the JIT has profiling data immediately at hand when doing optimization, whereas compiled languages won't. Even in cases where compiled languages do use profile feedback, it may not be representative of the current program usage.
Try writing a simple recursive Fibonacci number calculator in both C++ and Java. The Java one is faster, when using a JIT enabled JVM. Of course, that is a contrived example, but it shows that just-in-time compiling can be faster.
Extfs use a one-minute granularity
Also false. Ext2fs uses has a one second granularity, like most traditional Unix filesystems. This is easily demostratable with "ls -l -time-style=full-iso". While this is still a fairly coarse measurement, I've never seen a problem in practice.
The GNU make has this bug even worse, since it only checks file size most of the time.
False. GNU make checks the last file modification time. If you have any problems getting consistant incremental builds, it is probably because the Makefile has incorrect dependency information. For example, if a header file changes the size of a struct, every source file that includes it should be recompiled. An automated tool like "gcc -MM" is the best way to ensure the dependencies are correct.
Your example is a bad one. Microsoft did its best to avoid starting over with its operating systems. And when it did, it did so very carefully with as much backwards compability as possible.
Windows will still run MS-DOS binaries and Windows 1.0 through Windows ME all ran atop the MS-DOS code base in one way or another. They started over exactly once, when they build NT. And they gave it over 7 years to mature before they dumped the old MS-DOS/Windows code. And even with this one example, they ensured it was as compatible as possible to the old, which is why almost any program written for Windows 95 (and many written for earlier OSs, too) will still work with XP, 7+ years later.
Operating systems are a particularly good analogy, too because, like e-mail, it is a critical piece of infrastructure that depends heavily on interoperating with what else is out there.
Another reason for the x.99 to x.95 shift is for more practical reasons. Bricks and mortar retail outlets simply want to reduce the usage of pennies. Management of cash is still an issue for businesses, and if they can reduce their reliance on bulky pennies for the cost of four cents a sale, it is sometimes worth it, particularly if they deal in high volumes. (Even so, since pennies are still legal tender, they can't ignore them completely.)
Of course, that reason is completely irrelevent to internet sales, so I would predict less x.95's than in the real world.
The problem with curl or wget is that they handle only the most simple transmission problems. They can resume a file that got cut off before the end.
Rsync can handle any form of corruption: even the file somehow gets bad bits in the middle of it, you can just rerun rsync and it finds the corrupt sections and fixes it up.
Of course, newer P2P apps like BitTorrent are just as good as rsync at fixing corrupted files, but with the additional advantage of being able to download from multiple peers at once. Rsync definately has its place, but for ISOs, BitTorrent is the best I've seen yet.
Dark City. Very similar themes to the Matrix, but more toned down, less attitude.
If they do release RH9, it would be nice if they would release 8.1 at the same time. Even if its just RH8 with all the errata and security updates, it would be nice to have a solid distribution I can install from CD and not have to download 100's of megabytes in patches post install.