Actually, developers really make the best testers. When all developers work to build solid test cases for all of their code, and then run regular regression tests, the number of bugs in software dramatically decreases, as well as the likelihood that new bugs will be introduced with changes. Of course, the problem is that sometimes changes necessitate maintenance of the test cases themselves, which can be costly. It's usually an overall win, however. The initial investment is high, but the payoff over time is tremendous.
It would be nice to see the capabilities system completed so that it can actually be used. I think this would only involve adding capability bits to the filesystems and checking and setting those before executing programs. Finishing this would go really far to get rid of programs running as root unnecessarily. Anyone know why it hasn't been done already?
I'm glad I read the replies before posting a comment, because I was about to duplicate yours....
To sum it up, why add stupid little toys to browsers when there are extremely well designed features which haven't been implemented yet by anyone, despite the fact that they've been published standards since 1996 (CSS-1)?
While CSS-2 and XML give you the ability to separate content and presentation, I think it's equally important to point out the power of the DOM. It gives JavaScript complete control over the content of a page in a very flexible manner. Things which traditionally required a round-trip HTTP request to a server, such as adding a row to a table, now can be done without any network communication at all. Clever use of this can greatly reduce the amount of network traffic a web application generates, in addition to an overall speed gain. Instead of refetching an entire page repeatedly while working on it, you only have to request a fragment containing the information you need, or possibly no HTTP requests at all if you're able to anticipate information they might need and send it up front, but don't display it. As anyone who's tried to use a web application knows, waiting for a server's responses (especially long ones) is usually how you spend (waste?) the majority of your time.
With all of this amazing power just waiting for implementation, why would anyone want more gimmicks? Standards often get in the way of the cool stuff my *ss. I assume you're talking about really cool stuff, like the BLINK tag...
I've been forced to use JSP at work, and can't say that I'm too fond of it. It's a very powerful, solid web language. However, this power is it's weakness. Code and content really should not be mixed for anything more than just presentational logic. However, with JSP you have the ability to write arbitrary Java amongst your HTML. How can this be a bad thing? Well, if you make a concerted effort across your entire team to abstract the guts of your code into beans, you'll do pretty well. However, if you're in a rush (like most companies are), that standard will be the first thing thrown out the window, and you'll end up with a hairy mess: imagine 6 HTML pages within a single JSP, selected with a switch statement, where the main body of various tables are drawn by functions defined at the top of the file. Try handing that thing over to your web designers. Believe, they won't be able to make a dent, and you'll end up with a site designed by developers. It'll be very nasty.
Of course, ASP shares these same problems, as JSP was modeled after it. The real solution to this problem is to use a scripting language which doesn't allow the intermingling of Java code and presentation. An example would be WebMacro or Velocity, template engines which use a very simple scripting language to access bean properties to display a page. A servlet inspects the HTTP request, performs all logic for deciding how to handle this request, constructs a bean representation of the data requested, and then passes this data to the template for display. This seperation is clean--the servlet is written by a Java programmer, the template by a graphics artist. They only need to communicate about what data will be passed between the two. It also enforces good style of not allowing arbitrary code to appear in your presentation layer--something which requires a fair amount of discipline--especially with junior developers--when working with JSP.
The main thing JSP has going for it right now is market push. JSP was just a clone of ASP in an attempt to win mindshare by providing something familiar. {A,J}SP really isn't very well thought-out, but most people don't realize this because they don't know much about the alternatives. Compound this with the fact that developers don't mind mixing code and content, and you've got a pretty strong force in favor of something which can make web monkey's lives a living hell. It's really a good idea to look at the alternatives. Unfortunately, none of them have really reached the critical mass of users yet, but as sooner we make the transition, the faster they'll mature!
The traditional problem with ultra-high speed photography is getting the film to expose quickly enough--and the way you solve that problem is by using an obscene amount of lighting to get the shot. The intense heat produced by the lights actually puts a limit on the shots that can be taken--things which melt or distort when heated can't really be filmed in traditional slow-motion. Since digital removes the film exposure problem, perhaps this problem's days are numbered?
Of course, the digital sensors might still need a lot of light to work at higher speeds. Does anyone know for sure?
If RedHat had shipped all of their admin tools compiled against Inti, I might be able to understand your frustration. But as it currently stands, Inti is just a development library for interested people to try out. Sure, it's pretty far from complete, but since you have to actually do some research (i.e. reading API docs, at the very least) before using it, RedHat can be fairly sure that anyone trying to use it will be aware that it's incomplete. Actually, I'm puzzled as to how you managed to miss it! They're just trying to generate interest in their new class library. It's how Free Software development works. Generate some interest, get more testers and coders. There's no need to flame them for practicing their own art.
I wouldn't be too surprised if they switched them to use the UltraSparc III, as well. I think Sun is trying to sell lots of small, cheap boxes with the Sparc III so that they can ramp up production on them to get the benefits of volume that Intel has. Sure, they won't get anywhere near the same numbers as Intel, but hopefully they can bring their costs down so that Sun hardware isn't so much more expensive than Intel that they just can't compete on the low end--at all--as has been true in the past.
You could also use a zero-knowleged proof of identity, such as SRP. The problem with most forms of crypto is that they require an interactive protocol with several exchanges, and the security is compromised if any of those exchanges occur out of order. This doesn't fit well within the HTTP request/response scheme.
However, there are zero-knowledge protocols which are noniteractive. See page 106 of Applied Cryptography, 2nd ed.
These weren't streaming formats. The video feeds were actually being saved to disk for playback later--they were pay-per-view movies, and customers wouldn't be too happy about degraded quality. A new batch of movies had to be transferred every few weeks, and since you have to pay for the satellite access, it was best to get the transfer done as quickly and cheaply as possible.
Yes, two-way access over satellites is a problem. In our case, it didn't work at all, and is what caused the architecture I described--the receiver would wait until the transmission had finished, and then make a request for the missing parts, but over a different network, and the reply would come back over this same network. The satellite links were only used for the multicast distribution.
I used to work for a company which produced a multicast distribution system for large video feeds for cable companies. We handled the dropped packet situation by using forward error correction. That is, each packet was overspecified, so that a lost packet could be reconstructed from the packets which did get received. To catch the event that a lot of packets got lost in a row, thus defeating the forward error correction, we simply transmitted meta information at the beginning of the file, including a size and checksum. Then, after the receiver had finished receiving the file, the checksum of the received file was computed, and if it didn't match, it would contact the server and indicate that there were errors in transmission, and a retransmission would be scheduled. If the forward error correction indicated which sections of the file were corrupt or lost, it could request that only those sections be retransmitted
Using this scheme, most hosts get the file correctly on the first try, and those which don't usually only need a few extra packets to finish the job. Only a very small number of hosts need a full retransmit, which is equivalent to a single FTP session. The savings are phenomenal.
The difference was that the networks our product ran on were private (mostly satellite) links. I've never really tried to use multicast over the IPV4 internet, nor the MBONE. I'm not sure how well they would work.
I kind of get the feeling that some of this may have actually been intentional on id's part. I mean, they forgot to mention that the release is a beta?! Something seems fishy...basically, they want to introduce some new code, but they need it to be tested. This new code basically breaks everything, so that no one will recommend upgrading to it. Given this situation, how do you find people to test? Forget to mention that it's a beta. Then all those people (we all know those people) who like to have every little update for everything installed the day it comes out will be your unwitting testers (won't they ever learn?). Mission accomplished. Sure, this paints id in a pretty bad light, but how long has it been since the last update? I find it hard to believe that this was rushed, and things this important were accidentally omitted.
You make it sound like "subtle design issues" are nothing really major and can be ignored for the most part. In fact, those are the sorts of bugs that can take weeks or even months to find. I'd much rather just rewrite (if necessary) some moron's throwaway code than search for these sorts of beasties.
Put this together with FreeS/WAN, and you've got a good IPSec solution without having to buy the extra IPSec module from Cisco. As long as your router isn't heavily overworked, it could certainly do the job without a dedicated encryption card...
Just because Scheme and Haskell are both classified as functional languages does not make them equivalent for this particular argument. The difference is that Haskell is purely functional (local variables don't exist) while Scheme is not. It's this property of Haskell that can sometimes make things more complicated to implement than they would be in a procedural language. However, there are many useful properties (like easier proofs of correctness) of programs written in a purely functional manner that would are lost by implementing in a procedural language or a hybrid like Scheme.
Re:Network Filing System??
on
Is UNIX An OS?
·
· Score: 1
Not only that, but he had the audacity to assert that NFS actually made UNIX stable, something we know isn't the case. What happens when a server crashes in a non-NFS environment? You might not notice for a while, but when you do, you reboot it. When it goes down and it's your NFS server? Every single client you have hangs until you go and get that machine back up. This isn't a more stable environment, just more uniform.
I really like the idea FairTunes has (I spent $25 there a few days ago), but I'm not so sure it's ever going to be a big hit. When I gave my money to them, I assumed they had been around for a while and had already processed a large number of transactions. It was only *after* I'd finished that I found out they'd received a total of $200. That was a few days ago--by now they're up to just under $300. It looks like only 6 people have contributed since then. Of course, this is probably due to a lack of exposure, but I'm still not convinced that many people would be inclined to voluntarily contribute. American society just isn't geared that way. It shouldn't be hard to convince artists that they would get a bigger percentage without the record companies (only the credit cards get a percentage in this case), but it will be hard to convince them that it will be a large percentage of a reasonable amount if it's only collected on a voluntary basis.
Getting DMA working on VIA 82Cxxx chipsets is more complicated than just using hdparm. I've outlined the parameters needed when compiling the kernel above, but heres the relevant section from my/usr/src/linux/.config:
# ATA/IDE/MFM/RLL support CONFIG_IDEDMA_PCI_EXPERIMENTAL=y CONFIG_IDEDMA_PCI_WIP=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_VIA82CXXX_TUNING=y
It seems that the test system was a K6-400 with a VIA ide chipset. It was probably an Apollo Pro, which isn't very well supported by Linux at the moment. Examining the filesystem performance graphs shows around 3 MB/s throughput, which is exactly what I was getting out of my Apollo before I got UDMA working with it. You have to apply the IDE patches to 2.2 to even have it available, though it's in the 2.4-test series. You need to enable support for VIA82CXXX, ATA Works in Progress, Use PCI DMA by default when available, and VIA82CXXX Tuning support (a work in progress). After doing these things, I get 22 MB/s (!) out of my IBM, and 19 MB/s out of my Western Digital. If the Linux kernels had been compiled with these options, the results of the tests would have been quite different, I'd say.
Where does that new-fangled internet music come from? It's ripped from CD's, right? What if music didn't come on CD's anymore, but only some unrippable media? Joe Schmoe will *have* to look back.
Yes, you'll always be able to rip an analog copy of digital media, but if hardware vendors get together (think DVDCA, but having learned from their mistakes) then they could prevent us from intercepting the music. Your assumption is that the cleartext stream passes somewhere usable to you. What if soundcards had native support for an encrypted music format? All you would see is meaningless garbage on the way in, and you're only interceptable output would be analog (until soundcards have digital outputs...but then they could just pass the encrypted stream to the next piece of hardware, assuming it too knew how to decrypt the format). Granted, this sort of thing would be very hard to keep secret, just like the DVD fiasco, but never underestimate cryptographers.
However, there does seem to be a lot of stuff left over from C/C++ days that is sort of questionable. Like the inclusion of structs and enums. The potential performance benefits of structs are intriguing, but losing much of the OOP nature of your code is not attractive. Enums seem to clutter the language needlessly.
Enums are actually a nice addition. If there's one thing about Java that drives me nuts, its the fact that I have to keep track of lots of public static final int foo = x; statements. If the enum support were flexible enough to use more types than just int's, it would be very welcome, indeed. Imagine String constants as method arguments with compile-time checking to make sure that only valid constants are ever passed to the method. Useful, no?
rm -rf/etc is a bit overboard for a comparison to deleting preferences. *Far* more things go into/etc than simple configuration options. In fact, system boot scripts (and inittab) go there. Without/etc, the system will be completely unusable (it won't boot). However, the saving grace is that/etc and most files in it are owned by root. Deleting Mac preferences is much more akin to doing rm -rf ~/.gnome* Annoying, but certainly not crippling.
You won't be able to reduce a solution proving P=NP to ATM or the Halting problem because those problems are neither in P nor NP. They are undecidable. *No* algorithm solves them. There's no need to worry about how efficiently an algorithm *doesn't* solve them.:-)
Slashdot Mirror
Actually, developers really make the best testers. When all developers work to build solid test cases for all of their code, and then run regular regression tests, the number of bugs in software dramatically decreases, as well as the likelihood that new bugs will be introduced with changes. Of course, the problem is that sometimes changes necessitate maintenance of the test cases themselves, which can be costly. It's usually an overall win, however. The initial investment is high, but the payoff over time is tremendous.
It would be nice to see the capabilities system completed so that it can actually be used. I think this would only involve adding capability bits to the filesystems and checking and setting those before executing programs. Finishing this would go really far to get rid of programs running as root unnecessarily. Anyone know why it hasn't been done already?
To sum it up, why add stupid little toys to browsers when there are extremely well designed features which haven't been implemented yet by anyone, despite the fact that they've been published standards since 1996 (CSS-1)?
While CSS-2 and XML give you the ability to separate content and presentation, I think it's equally important to point out the power of the DOM. It gives JavaScript complete control over the content of a page in a very flexible manner. Things which traditionally required a round-trip HTTP request to a server, such as adding a row to a table, now can be done without any network communication at all. Clever use of this can greatly reduce the amount of network traffic a web application generates, in addition to an overall speed gain. Instead of refetching an entire page repeatedly while working on it, you only have to request a fragment containing the information you need, or possibly no HTTP requests at all if you're able to anticipate information they might need and send it up front, but don't display it. As anyone who's tried to use a web application knows, waiting for a server's responses (especially long ones) is usually how you spend (waste?) the majority of your time.
With all of this amazing power just waiting for implementation, why would anyone want more gimmicks? Standards often get in the way of the cool stuff my *ss. I assume you're talking about really cool stuff, like the BLINK tag...
Of course, ASP shares these same problems, as JSP was modeled after it. The real solution to this problem is to use a scripting language which doesn't allow the intermingling of Java code and presentation. An example would be WebMacro or Velocity, template engines which use a very simple scripting language to access bean properties to display a page. A servlet inspects the HTTP request, performs all logic for deciding how to handle this request, constructs a bean representation of the data requested, and then passes this data to the template for display. This seperation is clean--the servlet is written by a Java programmer, the template by a graphics artist. They only need to communicate about what data will be passed between the two. It also enforces good style of not allowing arbitrary code to appear in your presentation layer--something which requires a fair amount of discipline--especially with junior developers--when working with JSP.
The main thing JSP has going for it right now is market push. JSP was just a clone of ASP in an attempt to win mindshare by providing something familiar. {A,J}SP really isn't very well thought-out, but most people don't realize this because they don't know much about the alternatives. Compound this with the fact that developers don't mind mixing code and content, and you've got a pretty strong force in favor of something which can make web monkey's lives a living hell. It's really a good idea to look at the alternatives. Unfortunately, none of them have really reached the critical mass of users yet, but as sooner we make the transition, the faster they'll mature!
Of course, the digital sensors might still need a lot of light to work at higher speeds. Does anyone know for sure?
If RedHat had shipped all of their admin tools compiled against Inti, I might be able to understand your frustration. But as it currently stands, Inti is just a development library for interested people to try out. Sure, it's pretty far from complete, but since you have to actually do some research (i.e. reading API docs, at the very least) before using it, RedHat can be fairly sure that anyone trying to use it will be aware that it's incomplete. Actually, I'm puzzled as to how you managed to miss it! They're just trying to generate interest in their new class library. It's how Free Software development works. Generate some interest, get more testers and coders. There's no need to flame them for practicing their own art.
I wouldn't be too surprised if they switched them to use the UltraSparc III, as well. I think Sun is trying to sell lots of small, cheap boxes with the Sparc III so that they can ramp up production on them to get the benefits of volume that Intel has. Sure, they won't get anywhere near the same numbers as Intel, but hopefully they can bring their costs down so that Sun hardware isn't so much more expensive than Intel that they just can't compete on the low end--at all--as has been true in the past.
However, there are zero-knowledge protocols which are noniteractive. See page 106 of Applied Cryptography, 2nd ed.
Yes, two-way access over satellites is a problem. In our case, it didn't work at all, and is what caused the architecture I described--the receiver would wait until the transmission had finished, and then make a request for the missing parts, but over a different network, and the reply would come back over this same network. The satellite links were only used for the multicast distribution.
Using this scheme, most hosts get the file correctly on the first try, and those which don't usually only need a few extra packets to finish the job. Only a very small number of hosts need a full retransmit, which is equivalent to a single FTP session. The savings are phenomenal.
The difference was that the networks our product ran on were private (mostly satellite) links. I've never really tried to use multicast over the IPV4 internet, nor the MBONE. I'm not sure how well they would work.
I kind of get the feeling that some of this may have actually been intentional on id's part. I mean, they forgot to mention that the release is a beta?! Something seems fishy...basically, they want to introduce some new code, but they need it to be tested. This new code basically breaks everything, so that no one will recommend upgrading to it. Given this situation, how do you find people to test? Forget to mention that it's a beta. Then all those people (we all know those people) who like to have every little update for everything installed the day it comes out will be your unwitting testers (won't they ever learn?). Mission accomplished. Sure, this paints id in a pretty bad light, but how long has it been since the last update? I find it hard to believe that this was rushed, and things this important were accidentally omitted.
You make it sound like "subtle design issues" are nothing really major and can be ignored for the most part. In fact, those are the sorts of bugs that can take weeks or even months to find. I'd much rather just rewrite (if necessary) some moron's throwaway code than search for these sorts of beasties.
Put this together with FreeS/WAN, and you've got a good IPSec solution without having to buy the extra IPSec module from Cisco. As long as your router isn't heavily overworked, it could certainly do the job without a dedicated encryption card...
This idea is good, but it doesn't meet the basic needs of translation: grammar differences might require that the %d and %s be switched.
Just because Scheme and Haskell are both classified as functional languages does not make them equivalent for this particular argument. The difference is that Haskell is purely functional (local variables don't exist) while Scheme is not. It's this property of Haskell that can sometimes make things more complicated to implement than they would be in a procedural language. However, there are many useful properties (like easier proofs of correctness) of programs written in a purely functional manner that would are lost by implementing in a procedural language or a hybrid like Scheme.
Not only that, but he had the audacity to assert that NFS actually made UNIX stable, something we know isn't the case. What happens when a server crashes in a non-NFS environment? You might not notice for a while, but when you do, you reboot it. When it goes down and it's your NFS server? Every single client you have hangs until you go and get that machine back up. This isn't a more stable environment, just more uniform.
I really like the idea FairTunes has (I spent $25 there a few days ago), but I'm not so sure it's ever going to be a big hit. When I gave my money to them, I assumed they had been around for a while and had already processed a large number of transactions. It was only *after* I'd finished that I found out they'd received a total of $200. That was a few days ago--by now they're up to just under $300. It looks like only 6 people have contributed since then. Of course, this is probably due to a lack of exposure, but I'm still not convinced that many people would be inclined to voluntarily contribute. American society just isn't geared that way. It shouldn't be hard to convince artists that they would get a bigger percentage without the record companies (only the credit cards get a percentage in this case), but it will be hard to convince them that it will be a large percentage of a reasonable amount if it's only collected on a voluntary basis.
# ATA/IDE/MFM/RLL support
CONFIG_IDEDMA_PCI_EXPERIMENTAL=y
CONFIG_IDEDMA_PCI_WIP=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_VIA82CXXX_TUNING=y
It's still handled by the VIA82CXXX driver, so these parameters still *need* to be set to get UDMA working.
It seems that the test system was a K6-400 with a VIA ide chipset. It was probably an Apollo Pro, which isn't very well supported by Linux at the moment. Examining the filesystem performance graphs shows around 3 MB/s throughput, which is exactly what I was getting out of my Apollo before I got UDMA working with it. You have to apply the IDE patches to 2.2 to even have it available, though it's in the 2.4-test series. You need to enable support for VIA82CXXX, ATA Works in Progress, Use PCI DMA by default when available, and VIA82CXXX Tuning support (a work in progress). After doing these things, I get 22 MB/s (!) out of my IBM, and 19 MB/s out of my Western Digital. If the Linux kernels had been compiled with these options, the results of the tests would have been quite different, I'd say.
Where does that new-fangled internet music come from? It's ripped from CD's, right? What if music didn't come on CD's anymore, but only some unrippable media? Joe Schmoe will *have* to look back.
Yes, you'll always be able to rip an analog copy of digital media, but if hardware vendors get together (think DVDCA, but having learned from their mistakes) then they could prevent us from intercepting the music. Your assumption is that the cleartext stream passes somewhere usable to you. What if soundcards had native support for an encrypted music format? All you would see is meaningless garbage on the way in, and you're only interceptable output would be analog (until soundcards have digital outputs...but then they could just pass the encrypted stream to the next piece of hardware, assuming it too knew how to decrypt the format). Granted, this sort of thing would be very hard to keep secret, just like the DVD fiasco, but never underestimate cryptographers.
Enums are actually a nice addition. If there's one thing about Java that drives me nuts, its the fact that I have to keep track of lots of public static final int foo = x; statements. If the enum support were flexible enough to use more types than just int's, it would be very welcome, indeed. Imagine String constants as method arguments with compile-time checking to make sure that only valid constants are ever passed to the method. Useful, no?
rm -rf /etc is a bit overboard for a comparison to deleting preferences. *Far* more things go into /etc than simple configuration options. In fact, system boot scripts (and inittab) go there. Without /etc, the system will be completely unusable (it won't boot). However, the saving grace is that /etc and most files in it are owned by root. Deleting Mac preferences is much more akin to doing rm -rf ~/.gnome* Annoying, but certainly not crippling.
You won't be able to reduce a solution proving P=NP to ATM or the Halting problem because those problems are neither in P nor NP. They are undecidable. *No* algorithm solves them. There's no need to worry about how efficiently an algorithm *doesn't* solve them. :-)