I doubt that subsidies really hurt the carries bottom line. About 3 years ago when I was last switching carriers, T-Mobile used to have two plans that provided the same minutes/text/data; one plan provided a discount on the phone but were required a two year contract while the other had no subsidy and no contract. In addition the plan with the subsidy cost $20 more a month for smartphones with dataplans. The typical discount on the smart phone was $250-$350. But the extra fees you paid over the life of the contract was $480. So over the life of the contract, you paid an extra $130-$230 to the carrier in exchange for a low start up cost.
(And T-Mobile had a similar thing with regular phones; charged an extra $10 a month / $240 over the life of the contract for a discount of $100-$150).
I highly doubt that any of the other carriers don't also make back the subsidy by higher per-month fees. Of course, I also wonder now that those carriers have gotten people used to a certain monthly fee, will they really lower them after taking away the subsidy.
One of the reasons I liked T-Mobile was that they gave me the option.
I really don't see why this is such a big deal. According to the article, there's.365 accidents per 100,000 miles or just a tad under 1.1 accidents for 300,000 miles. So while the self-driving cars are not having significantly more accidents per mile driven, they haven't logged nearly enough miles yet to clearly demonstrate they that have less accidents per mile driven.
Being able to create a single large product with a single programming language is a great skill, but so is being able to do Unix shell scripting.
The system/product I have been working on for the last 10 years is two major pieces that is about 90% of the total code base and lots of small pieces. The two major pieces are both essentially a single program that can be developed in unified environment. But we also have lots of small pieces that are shell scripts that are done in the classical Unix spirit.
Being able to work in both ways is a great strength for the engineers who can do that. Those who can only do one or the other are essentially marginalized as that limits what they are able to do.
This is not entirely accurate. I just heard from DDJ that an article of mine they accepted earlier this year is being published in February. I asked for one final change and told me that they could not do that because the issue had already gone to press.
Speakeasy sells Naked DSL as OneLink which is DSL without a separate land line. They charge an extra $6 a month which is cheaper than any land-line service.
Speakeasy DSL is on the pricey side (~$50 a month for 1.5 down, 384 up) but I believe they are well worth it. I have used them for about 6 years and never experienced an unannounced outage. They are owned by BestBuy now but so far I have not noticed any changes.
I use IE Tab Firefox Extension and it is a life saver for me. There are a couple of important pages on my company's intranet that require IE (yes, ActiveX crap). Not only can I have a one tab running the IE rendered while the rest of my tabs are using whatever the native Firefox rendered is, but you can configure the extension to always use IE for specific pages so once you configure that you don't have to remember which pages need IE.
Assuming you are talking about the SSL issue in Debian - the original 'issue' they tried to fix was reported by Valgrind. Valgrind is a run-time analysis tool.
While the parent makes a good point that results are not always easy to understand or fix - since the original post is about static vs run-time analysis tools, it's good to understand that they each have their problems.
While I have not written any assembly since college, I am really glad I know it. As an engineer who works in C/C++, sometimes it is really helpful in debugging to see what is happening at the assembly level.
So, I would definitely recommend at least being acquainted enough with assembly so that you can semi understand a listing.
Back in the early 90's, I was working on a Windows application for my company. I was unable to implement a feature in the ideal way because the Win16 API on Windows 3.1 did not give me the necessary support.
Not to long afterwards, I was reading Undocumented Windows by Andrew Schulman and lo and behold, I found that Windows 3.1 actually did support the functionality I had needed.
Most of the functionality in Windows 3.1 was found by reverse engineering various applications, mostly from Microsoft itself. Microsoft application developers were able to access APIs that were not publicly documented.
Microsoft has often claimed that people prefer their applications because they are better. But at least one of the reasons they are better is they gave themselves functionality that non-Microsoft application developers did not know about.
No, we did not lose any business because of the feature I was unable to develop. But it proved to me that Microsoft did not play fair.
I am reading the description quite differently. On the Blackberry, once you have a developer key you automatically have access to every Blackberry out there. Furthermore, it does not appear like there is a simple way for the owner of a Blackberry to prevent this. While they could block a known developer key that has malicious software associated with it, what prevents someone from just getting another key.
Root passwords are completely different. They are unique to the machine. If you convince your friend to give you his root password, then you are in. But that is different then convinving RedHat or SuSE or whoever from giving you a key that can get you into any Linux install.
Anybody know of any usefull [sic] tools to completely wipe the contents of a drive?
Darik's Boot and Nuke (aka DBAN) available at Sourceforge. It has various settings depending on how paranoid you need to be and how much time you want to take.
What good is it to be able to continue to run a kernel even with your SCSI drive disabled, if all your software to fix the problem is on the SCSI drive?
One benefit is that you can restart the SCSI driver without rebooting the entire machine. For now, this simply means quicker restarts, but once software can be written to make use of this knowledge, software can be taken to higher level.
Consider a server for a network file system. If you need to reboot the machine just to restart the disk subsystem, you lose all network communication. Client software can not know what the problem is and cannot react to it in anyway beyond the most basic fashion (and furthermore, things will be nice and slow while those network packets are timing out).
But with a microkernel OS and a server that is aware of this, the protocol can be designed to let the client know what is going on. The server can even choose to accept the data across the network with the expectation that the disk subsystem will come back up within a short period of time.
The most common data model in C for 64 bit programming is LP64. In this model, longs and pointers are 64 bits while ints are still 32.
In Java longs are already 64 bits which basically makes Java code 64 bit ready. If there is going to be any troubles, it will be with sloppy C code that assumes sizeof(int) == sizeof(long).
I don't see how VP Cheney will allow this to happen. Without DARPA doing basic research, the Internet would not exist as we know it. And without the Internet, no eBay. And without eBay, our economy would truly be in the dumps.
That puts a pretty huge price on false positives. A piece of email gets incorrectly identified as spam so the firewall closes the TCP connection. To the sending MTA, that looks just like a network problem so it attempts to resend the email. Because of that, the firewall then starts refusing all email from that IP.
Let me know what product you are working on so I can make sure not to buy it.
I understand a "spam firewall" to close the connection as soon as it recognises spam, rather then let the whole email download.
While that is a possible definition, attempting to implement that would lead to various problems.
If the firewall just closes the underlying TCP connection, the sending MTA will most likely assume there was a network problem and send the message again later. This means that even though the firewall has identified a message as spam once, it will have to filter it again later. Depending on the logic of the sending MTA, it may try to resend messages where the network connection was closed many times before giving up.
So, a better method would be to use the SMTP protocol and return a 5xx error code to let the sending MTA know it shouldn't attempt to resend the message later. The problem here is that this can only be done prior to receiving any of the message or after the entire message has been received. There is no way to send an STMP error code after seeing some of the message body.
So, either the firewall closes the TCP connection without using the SMTP protocol, it has to make a spam determination prior to seeing any of the message or it can't save any bandwidth. None of these methods seem particulary robust to me.
Since the focal point is the webserver, shouldn't security be done there, rather than the DB?
Security should be done in every layer of the system. If you only did security on the web server, if crackers are able to compromise it, getting into the database is simple at that point. But if they can only run stored procedures, they then need to find a hole in the database which halves the likelihood of getting in.
Of course there are all the costs of maintaining the extra level of security. So you have to consider the cost/benefit of the security you put in place.
My personal theory of why code is so buggy is that API design is given such short thrift. I have had to fix way too many bugs where the problem is that the code was using an API incorrectly. I would further say that 80% of the time, the API is so poortly designed that it is next to impossible to use it right.
One of the biggest problems is that too many APIs do not have clear definitions of what their semantics are. The semantics just end up being by products of the engineer who implemented the code. Often times these semantics match what is needed by the first user of the API rather then trying to properly generalize it.
Also, without clear semantics, it becomes impossible to fix a buggy implementation. Since their is no clear definition of what the library is defined to do, callers end up relying on unguaranteed semantics.
But the truth is, people don't want to choose, they want you to choose for them.
I partially agree with you here in that people don't want to have to choose desktops/OSs/whatever underlying technology. I would say the average user simply wants to choose what application she wants/needs. But they don't want to have their choice dictate that they need to change their whole environment. And they don't want to hear that they shouldn't choose app A and app B because app A doesn't run well on Gnome and app B doesn't run well on KDE.
Yes, the article is about C, but the poster was talking about predictable destruction, so he was not referring to C when dissing GC.
My guess is that he or she was referring to C++ using the RAII (resource acquisition is initialization) paradigm. Every resource is wrapped in a object and all objects are put on the stack. Voila, no resource leaks.
Also, I think your example is far from complete. While failing to close a file handle may be "no problem whatsoever" for the application itself, but can be a problem in the larger context. Some platforms will not allow a file to be deleted when it is open. If a programmer forgets to close a file handle, the user may not be able to delete the file until some time in the future. Far from an ideal situation.
And consider a different example. Think about trying to create a different synch primitive such as a reader-writer lock. Under a GC system, the programmer is still required to release the lock. If he doesn't, the system could essentially hang.
As for the finally clause, we all know that guaranteeing that there is no path that allows leaks is just plain damn hard to do. If finally was such a great answer, why even both with GC, just free data in the finally clause.
> The run queue is scanned, and when a process is > found that can be run, it is automatically run > without scanning the rest of the queue
> This scheduler is O(1) because it runs the first > process it can run without scanning the entire > queue
It sounds to me like you are missing an important piece of information to make it O(1). If the run queue was truly in some random order, then on average, the scheduler would have to scan 1/2 the list before finding a process to run. Then it would continue to be an O(n).
If there was something that could guarantee that a runnable process would always be close to the head of the run queue, then that would make it O(1).
So the question I have is what makes sure the run queue is ordered properly and is itself O(1)?
My article simply points out that the paradoxical effect of these "enforcement actions" (FSF's term) may be to impede the adoption of Linux.
That is an interesting but very myopic comment. One could just as easily say that the pardoxical effect of charging money may be to impede the adoption of Windows.
But no with half a brain would ever make that point. The goal of a corporation is to make profit and adoption of their software is simply a means to an end.
And my experience with my friends who license with GPL is that their goal is to affect a social change in how software is used and distributed. If their goal is simply go get as much adoption as possible, they would most likely use a different license.
Once again, the problem is that for many people, any goal that is not about making money is just incomprehensible. In the end, this story is just another sad commentary on our society's priorities.
Slashdot Mirror
I doubt that subsidies really hurt the carries bottom line. About 3 years ago when I was last switching carriers, T-Mobile used to have two plans that provided the same minutes/text/data; one plan provided a discount on the phone but were required a two year contract while the other had no subsidy and no contract. In addition the plan with the subsidy cost $20 more a month for smartphones with dataplans. The typical discount on the smart phone was $250-$350. But the extra fees you paid over the life of the contract was $480. So over the life of the contract, you paid an extra $130-$230 to the carrier in exchange for a low start up cost.
(And T-Mobile had a similar thing with regular phones; charged an extra $10 a month / $240 over the life of the contract for a discount of $100-$150).
I highly doubt that any of the other carriers don't also make back the subsidy by higher per-month fees. Of course, I also wonder now that those carriers have gotten people used to a certain monthly fee, will they really lower them after taking away the subsidy.
One of the reasons I liked T-Mobile was that they gave me the option.
I really don't see why this is such a big deal. According to the article, there's .365 accidents per 100,000 miles or just a tad under 1.1 accidents for 300,000 miles. So while the self-driving cars are not having significantly more accidents per mile driven, they haven't logged nearly enough miles yet to clearly demonstrate they that have less accidents per mile driven.
You should check out Scripting Layer for Android (SL4A).
Can they teach the controversy that George Bush stole in 2000 election?
Being able to create a single large product with a single programming language is a great skill, but so is being able to do Unix shell scripting.
The system/product I have been working on for the last 10 years is two major pieces that is about 90% of the total code base and lots of small pieces. The two major pieces are both essentially a single program that can be developed in unified environment. But we also have lots of small pieces that are shell scripts that are done in the classical Unix spirit.
Being able to work in both ways is a great strength for the engineers who can do that. Those who can only do one or the other are essentially marginalized as that limits what they are able to do.
This is not entirely accurate. I just heard from DDJ that an article of mine they accepted earlier this year is being published in February. I asked for one final change and told me that they could not do that because the issue had already gone to press.
Speakeasy sells Naked DSL as OneLink which is DSL without a separate land line. They charge an extra $6 a month which is cheaper than any land-line service.
Speakeasy DSL is on the pricey side (~$50 a month for 1.5 down, 384 up) but I believe they are well worth it. I have used them for about 6 years and never experienced an unannounced outage. They are owned by BestBuy now but so far I have not noticed any changes.
I use IE Tab Firefox Extension and it is a life saver for me. There are a couple of important pages on my company's intranet that require IE (yes, ActiveX crap). Not only can I have a one tab running the IE rendered while the rest of my tabs are using whatever the native Firefox rendered is, but you can configure the extension to always use IE for specific pages so once you configure that you don't have to remember which pages need IE.
Assuming you are talking about the SSL issue in Debian - the original 'issue' they tried to fix was reported by Valgrind. Valgrind is a run-time analysis tool.
While the parent makes a good point that results are not always easy to understand or fix - since the original post is about static vs run-time analysis tools, it's good to understand that they each have their problems.
While I have not written any assembly since college, I am really glad I know it. As an engineer who works in C/C++, sometimes it is really helpful in debugging to see what is happening at the assembly level.
So, I would definitely recommend at least being acquainted enough with assembly so that you can semi understand a listing.
Back in the early 90's, I was working on a Windows application for my company. I was unable to implement a feature in the ideal way because the Win16 API on Windows 3.1 did not give me the necessary support.
Not to long afterwards, I was reading Undocumented Windows by Andrew Schulman and lo and behold, I found that Windows 3.1 actually did support the functionality I had needed.
Most of the functionality in Windows 3.1 was found by reverse engineering various applications, mostly from Microsoft itself. Microsoft application developers were able to access APIs that were not publicly documented.
Microsoft has often claimed that people prefer their applications because they are better. But at least one of the reasons they are better is they gave themselves functionality that non-Microsoft application developers did not know about.
No, we did not lose any business because of the feature I was unable to develop. But it proved to me that Microsoft did not play fair.
I am reading the description quite differently. On the Blackberry, once you have a developer key you automatically have access to every Blackberry out there. Furthermore, it does not appear like there is a simple way for the owner of a Blackberry to prevent this. While they could block a known developer key that has malicious software associated with it, what prevents someone from just getting another key.
Root passwords are completely different. They are unique to the machine. If you convince your friend to give you his root password, then you are in. But that is different then convinving RedHat or SuSE or whoever from giving you a key that can get you into any Linux install.
Anybody know of any usefull [sic] tools to completely wipe the contents of a drive?
Darik's Boot and Nuke (aka DBAN) available at Sourceforge. It has various settings depending on how paranoid you need to be and how much time you want to take.
What good is it to be able to continue to run a kernel even with your SCSI drive disabled, if all your software to fix the problem is on the SCSI drive?
One benefit is that you can restart the SCSI driver without rebooting the entire machine. For now, this simply means quicker restarts, but once software can be written to make use of this knowledge, software can be taken to higher level.
Consider a server for a network file system. If you need to reboot the machine just to restart the disk subsystem, you lose all network communication. Client software can not know what the problem is and cannot react to it in anyway beyond the most basic fashion (and furthermore, things will be nice and slow while those network packets are timing out).
But with a microkernel OS and a server that is aware of this, the protocol can be designed to let the client know what is going on. The server can even choose to accept the data across the network with the expectation that the disk subsystem will come back up within a short period of time.
http://wiki.x.org/wiki/Mirrors
The most common data model in C for 64 bit programming is LP64. In this model, longs and pointers are 64 bits while ints are still 32.
In Java longs are already 64 bits which basically makes Java code 64 bit ready. If there is going to be any troubles, it will be with sloppy C code that assumes sizeof(int) == sizeof(long).
I don't see how VP Cheney will allow this to happen. Without DARPA doing basic research, the Internet would not exist as we know it. And without the Internet, no eBay. And without eBay, our economy would truly be in the dumps.
That puts a pretty huge price on false positives. A piece of email gets incorrectly identified as spam so the firewall closes the TCP connection. To the sending MTA, that looks just like a network problem so it attempts to resend the email. Because of that, the firewall then starts refusing all email from that IP.
Let me know what product you are working on so I can make sure not to buy it.
I understand a "spam firewall" to close the connection as soon as it recognises spam, rather then let the whole email download.
While that is a possible definition, attempting to implement that would lead to various problems.
If the firewall just closes the underlying TCP connection, the sending MTA will most likely assume there was a network problem and send the message again later. This means that even though the firewall has identified a message as spam once, it will have to filter it again later. Depending on the logic of the sending MTA, it may try to resend messages where the network connection was closed many times before giving up.
So, a better method would be to use the SMTP protocol and return a 5xx error code to let the sending MTA know it shouldn't attempt to resend the message later. The problem here is that this can only be done prior to receiving any of the message or after the entire message has been received. There is no way to send an STMP error code after seeing some of the message body.
So, either the firewall closes the TCP connection without using the SMTP protocol, it has to make a spam determination prior to seeing any of the message or it can't save any bandwidth. None of these methods seem particulary robust to me.
Since the focal point is the webserver, shouldn't security be done there, rather than the DB?
Security should be done in every layer of the system. If you only did security on the web server, if crackers are able to compromise it, getting into the database is simple at that point. But if they can only run stored procedures, they then need to find a hole in the database which halves the likelihood of getting in.
Of course there are all the costs of maintaining the extra level of security. So you have to consider the cost/benefit of the security you put in place.
My personal theory of why code is so buggy is that API design is given such short thrift. I have had to fix way too many bugs where the problem is that the code was using an API incorrectly. I would further say that 80% of the time, the API is so poortly designed that it is next to impossible to use it right.
One of the biggest problems is that too many APIs do not have clear definitions of what their semantics are. The semantics just end up being by products of the engineer who implemented the code. Often times these semantics match what is needed by the first user of the API rather then trying to properly generalize it.
Also, without clear semantics, it becomes impossible to fix a buggy implementation. Since their is no clear definition of what the library is defined to do, callers end up relying on unguaranteed semantics.
But the truth is, people don't want to choose, they want you to choose for them.
I partially agree with you here in that people don't want to have to choose desktops/OSs/whatever underlying technology. I would say the average user simply wants to choose what application she wants/needs. But they don't want to have their choice dictate that they need to change their whole environment. And they don't want to hear that they shouldn't choose app A and app B because app A doesn't run well on Gnome and app B doesn't run well on KDE.
Yes, the article is about C, but the poster was talking about predictable destruction, so he was not referring to C when dissing GC.
My guess is that he or she was referring to C++ using the RAII (resource acquisition is initialization) paradigm. Every resource is wrapped in a object and all objects are put on the stack. Voila, no resource leaks.
Also, I think your example is far from complete. While failing to close a file handle may be "no problem whatsoever" for the application itself, but can be a problem in the larger context. Some platforms will not allow a file to be deleted when it is open. If a programmer forgets to close a file handle, the user may not be able to delete the file until some time in the future. Far from an ideal situation.
And consider a different example. Think about trying to create a different synch primitive such as a reader-writer lock. Under a GC system, the programmer is still required to release the lock. If he doesn't, the system could essentially hang.
As for the finally clause, we all know that guaranteeing that there is no path that allows leaks is just plain damn hard to do. If finally was such a great answer, why even both with GC, just free data in the finally clause.
> The run queue is scanned, and when a process is
> found that can be run, it is automatically run
> without scanning the rest of the queue
> This scheduler is O(1) because it runs the first
> process it can run without scanning the entire
> queue
It sounds to me like you are missing an important piece of information to make it O(1). If the run queue was truly in some random order, then on average, the scheduler would have to scan 1/2 the list before finding a process to run. Then it would continue to be an O(n).
If there was something that could guarantee that a runnable process would always be close to the head of the run queue, then that would make it O(1).
So the question I have is what makes sure the run queue is ordered properly and is itself O(1)?
My article simply points out that the paradoxical effect of these "enforcement actions" (FSF's term) may be to impede the adoption of Linux.
That is an interesting but very myopic comment. One could just as easily say that the pardoxical effect of charging money may be to impede the adoption of Windows.
But no with half a brain would ever make that point. The goal of a corporation is to make profit and adoption of their software is simply a means to an end.
And my experience with my friends who license with GPL is that their goal is to affect a social change in how software is used and distributed. If their goal is simply go get as much adoption as possible, they would most likely use a different license.
Once again, the problem is that for many people, any goal that is not about making money is just incomprehensible. In the end, this story is just another sad commentary on our society's priorities.