Lars Magne Ingebrigtsen <larzi@nospamgnus.org> writes:
> But just to test out that theory, this message has the address > larzi@nospamgnus.org. If I get mail to that address without the > spammy bits, then spammers have, indeed, grown brains.
Stop the presses! I just got a spam to that despammed address.
"You WILL make $7,500/month or it's FREE!"
They've apparently been growing brains. Probably hydroponically.
So some spammers have figured out string manipulation.
Are you serious? When I think "programming newbie", I think of someone who is having difficulty realizing that instructions are executed sequentially, one after the other, and that a variable's value will disappear if you overwrite it.[*] I remember getting very frustrated trying to explain to one of my college roommates how the value of a variable could change over time. (The model of a variable as a box that holds a value, and not merely a placeholder for a value, is not always as easy to explain as you might think; he was a bit confused that "a:= a + 1" didn't cause an infinite loop)
And you want to burden these people with a java environment? With a language that doesn't even have an interactive toplevel?
The read-eval loop that my first basic (on the TI/99 4A) started up with was something I never really appreciated until I watched someone else trying to learn to program purely through writing programs and compiling them. The mind really needs to have a chance to use and experiment with a concept to get it to sink in. For the fundamental concepts behind most programming languages, I really feel that this mandates an interactive toplevel; this is something no java environment I've ever seen offers. (As an aside: is there a nice beanshell plugin for Eclipse?)
This applies both to those learning to program on their own and to those learning as part of a formal class. Trying to learn the basics of programming without an interactive toplevel is a bit like trying to learn how to drive without ever walking first - you'd get so caught up in shifting gears and pushing pedals that you'd never get to figure out basic concepts like not getting lost when you can't see the house anymore.
[*] Yeah, yeah, some languages have control flow that doesn't follow this model, but I've never heard any of those proposed as first computer languages either. (Though I do think that my roommate might have done better starting out in Haskell than Pascal)
Using restrictive ACL's on your outbound interfaces, you can kill connectivity for most types of malicious connections. For protocols you MUST run - say HTTP, outgoing SQL, outgoing SMTP and the like - you *proxy* every single connection, and ensure each connection is authenticated.
This is, so far as I can tell, standard industry practice in certain places, and I'll tell you the result: everything gets tunnelled over HTTP.
When people have some brand new protocol (say, when Microsoft was developing SOAP), they'll make it so that it tunnels over HTTP. When some random company designs the protocol that their new data appliance uses to call home for updates and instructions, they'll tunnel it over HTTP. Eventually, every possible bit of functionality will be tunnelled over HTTP. Those trying to secure the network will have gained nothing except extra bandwidth and protocol overhead.
Face it guys - you're shooting yourselves in the foot here over the long term. When employees with the purchasing power and authority to place a machine on the network cannot get the network administrators to open up necessary port access (and if it's too much of a hassle to deal with the network security guys, then that's just as bad), you have the situation where network security will be circumvented.
Network security only exists with the active cooperation of informed employees; pretending that it's a purely technical problem that fancy network hardware can solve is just wishful thinking.
Squeak is a cross-platform implementation of smalltalk that has developed quite the little community of educators and students around it. It allows budding programmers to start on a very basic level - something reminiscent of hypercard - but underneath it all is a real language that allows all the power and syntax you might want. As soon as you're ready, the power is there.
The scheme environment bundled with How To Design Programs has a similar goal of allowing the student to gradually ramp up the complexity of the language, but I find their rigid levels confining. Also, the programs a beginning programmer is able to put together are nowhere near as satisfying visually as what a new squeak user can build. (These kids today - in my day, we had either text or 40 by 40 graphics and we liked it.) That said, the htdp scheme environment may be more appropriate for a structured classroom environment with a series of lessons.
My only complaint about squeak is the license (despite claims on squeak.org, it's not really an open source license because of the fonts it includes); however, it is free-as-in-beer and has been already been used in elementary and middle school classrooms for both teacher- and student-created projects. (See squeakland)
There's NOTHING wrong with being taught something for its own sake.
Actually, I'd say that there is. There's nothing wrong with learning a subject for its own sake or with studying a subject for its own sake.
However, "being taught" is something entirely different. (hint: it's passive voice; who's the actor?) I'll not argue the point much further (I've actually got other things to do than slashdot), but rather just point you to this wiki entry and encourage you to read the results of a a google search on "unschooling".
The key to getting PNG to work properly with Internet explorer is to flatten your image down to 256 colors (indexed). This also allows only single-bit transparency.
This is what I did with my user image for livejournal. Sure, it's not as nice as full 24-bit transparency, but it's everything you were able to get with (non-animated) GIFs, except with smaller files. (And, unlike most GIF usage, legal without buying a license)
Doing this to an image inside GIMP is pretty simple: Image->Mode->Indexed.
There's also the bizarre CSS3 trick mentioned in other comments to this article; I haven't tried that yet.
Oh, I know it's a troll, but here are some good reasons for using python:
Rapid development. For anything (like a P2P app) where the value increases mostly through network effects (how many other people are using the same product), translating ideas into working code is critically important.
Built-in, conveniently accessed hashes. (aka associative arrays) I program in java regularly, and it's a much bigger pain using a.get() call for every damn dictionary access than the same code in python. (or perl, for that matter) Any piece of syntax that gets in the way of seeing the forest for all the damn tree leftovers cluttering up your view should be eliminated.
Cross-platform independence.
As to your objections to python, I find them bizarre. Perhaps on the tracker of a very busy download the CPU speed/memory usage is significant, (witness his statement that several alternative trackers are being worked on) but in any client the entire process is completely network IO bound. As for the problems with Python's garbage collector - BitTorrent (well, the code of it that I've looked at so far) doesn't use recursive structures, so I don't see what the objection is there.
Also, "awkward approach towards object creation/destruction"? What exactly does Python do that you wish it didn't? It sounds to me like you're pining for the days before people realized that object destruction costs, and that therefore it's best left to a garbage collector that can operate at idle times.
Furthermore, there's nothing that says you can't be fairly compensated for your time in putting the source on CD and mailing it (just be sure to obey clause 3b of the GPL - you can't include the administrative overhead of keeping track of the source in your cost for producing a source CD)
Were I an embedded developer, here's what I'd do: 1) Read the GPL. It's not that long, and as license go is very, very readable. 2) Place a "GPL compliance" notice in the printed documentation (along with any other required compliance notices, like FCC or other legal notices) that says something like: "Some of the source code used in FOOPRODUCT is covered under the Gnu General Public License (Gnu GPL). Persuant to the terms of that license, FOOCOMPANY will supply the relevant source code on demand for three years from the date this product was sold. Send inquiries to gplcompliance@foocompany.com and refer to FOOPRODUCT build number 123456a." (or "refer to the model number stamped on the bottom of the unit")
When I first bought my first linux CD from LSL, they printed the required GPL notice around the edge on the top of the CD. You could probably shorten the notice a bit, too, and get it down to something that could easily be put on a disklabel.
Then, set up an autoresponder at that address that says "here's what a CD of the GPL'ed source costs for us to copy, here's how much we'll charge you for shipping and handling, here's who to contact to actually order the source".
Then, I'd prepare.iso's of the GPLed source that went into each release of the product - you do have everything under version control, right? - and stick them somewhere in permanent storage. You don't have to go nuts here, making sure that the iso is nicely structured or anything. Just put the source to the GPL'd parts in whatever format you already have it on the CD. No one says that you have to carefully think through UI considerations in your GPL section 3b compliance.
If it's part of the regular process for releasing a version of the product, (and archiving all the source somewhere permanent should be part of that regular process anyway) we're not talking about much additional overhead at all.
Actually, the grandparent post suggests the first viable attack on this that I've seen suggested here - the other attacks (network tricks, etc.) rely on Phoenix's BIOS designers being so amazingly technically incompetent that they wouldn't cryptographically sign the "kill yourself" message.
This attack, however, relies only on a single instance of minor social incompetence by a call-desk employee. Attacks like this have already been shown to work on large corporations who are supposedly in the business of verifying identity - remember when VeriSign handed out two certificates for "Microsoft Corporation" to people who just asked for them?
The disadvantage of this attack is that it would in all likelihood be relatively easy to trace who had done it - it's highly unlikely that Phoenix's call center would accept a "my laptop's been stolen" call from a pay phone, and their procedures may even call for confirming any theft report by calling the supposed rightful owner back.
However, depending on the relationship between Phoenix and the major OEMs, the attack may get easier - it may be much easier to get Phoenix to think that I'm a Dell call-center employee reporting the theft of Mr. BigWig's laptop than to convince Phoenix that I'm Mr. BigWig or his authorized representative. That's something we'll have to wait and see on - it all depends on how the social network between Phoenix and the large OEMs are designed.
I'm certain that there's no one thinking up a technical attack here on slashdot that's viable against this system in the field. However, I have a reasonable expectation of incompetence from large corporations when it comes to designing the social network half of this system.
A language neutral course like, say, Information Extraction, is not without implementation - the students still have several projects to implement and can't merely do pencil-and-paper work. However, the focus is not on which language is used, but rather on what the results of the program are. In other words, the implementation is not critiqued or dealt with in the course except in terms of the external results.
For example, in the one graduate-level computer course I took (I was a math major; CS was just for fun), we were explicitly told by the professor to implement our projects in "whatever language you want". And we did; I was somewhat boring with my choices of C for the number crunching and perl for turning the numbers into nice summary reports, but several people used java, there was a dedicated group of matlab people, and one guy did almost everything in scheme. Supposedly, someone also implemented the first project as about 10 different interacting sh scripts and GNU expr, but I think that was just exaggerated rumor.
If the requirements for the assignments had specifically included performance, you probably would have seen less variation (at least the shell script tricks would have been out), but in this class they didn't happen to. The resulting language choice was a result of students needing to get the job done, not professorial fiat.
The point is, once you get to graduate level work, (as the grandparent post was talking about) the language itself is just a tool with which to study other aspects of computer behavior. (Unless, of course, you're explicitly studying the possibilities of computer languages themselves) Of course the university (in Canada, "university" means almost exclusively graduate work, unlike here in the US) doesn't teach C - it shouldn't really be teaching any specific language except possibly as an example of what a certain language family looks like.
This only applies if you don't provide the source at the time that you provide the binaries. If you do that, you're off the hook (even if the person you gave the source to throws it away - they might be unable to give the software to someone else, but you are off the hook).
I remember when I first ordered a Debian CD from LSL - they had the GPL-required "will provide source" written offer written around the edge of the CD.
Aside from the fact that I don't know quite why this rant got attached to parent post it did, of course the industry looks like a sham when you look at it from where you are. Any white collar work looks like a sham until you've been around it long enough to either find the parts that honestly aren't a sham or have cognitive dissonance kick in. It's just the nature of the US job market - the market is not a moral engine, and expecting it to act as one is just a recipe for disillusion.
As for the 'morons' problem - the problem isn't really with people who are grossly incompetent. Those actually can be weeded out in job interviews or fired later without too much trouble. The problem is with people who, once you really get to know them outside an interview, no longer appear good enough to have hired, but are too good to go through what's necessary to fire them. The end result is that they float by, sometimes even being promoted so as to get them out of the way. (Though in all honesty, there are occasionally "just good enough" programmers who turn out to be tolerable or even good managers or customer representatives)
Now, because HR actually does get wind of this problem, they attempt to respond by hiring better people. Unfortunately, they don't really know how to filter out people who are "just barely good enough", so they respond the only way they know how (up the number of years required, up the academic requirements). Yes, it sucks, but it arguably isn't even their fault, since it's really very hard in a job interview setting to tell the difference between a good programmer and a "just good enough" programmer.
A month ago I was talking to a former coworker who is now with a small start-up as their lead programmer about the pain he was going through hiring new people. They have had to go to a system of one-week "trial hires" - after a good interview, they agree to pay you for one week and give you one assignment that should only take that long. If you can do it, and do it well, you're hired. If not, they're only out one week's worth of pay.
They were starting this system after having to let three different employees go each after about 8 weeks when it became clear that they weren't actually up to the level the company needed, despite getting past an interview that should have cleared out technical incompetency.
I don't know how that system's worked out for them in the long run since they had just started it when last I talked to him.
I can understand this ban only in a few specific industries that also run with very restrictive internet filtering; are you in one of those?
getting around IllegalAccessException
on
Hijacking .NET
·
· Score: 3, Insightful
Sure you do, if you try to access them without first calling setAccessible.
However, it's pretty easy to turn that exception off unless there's a SecurityManager installed.
Conclusion? Don't make any java code a security boundary without putting a SecurityManager properly in place. This also implies that java code at security boundaries has trouble being fast, but that's the case with any code at security boundaries.
Simply put if you dont have some sort of theoritical backing to you claim that one method id faster than another, it cant bebelieved.
I'd revise this statement to: "if you don't have some sort of evidence (experimental or hard theoretical) backing to your claim that one method is faster than another, your claim can't be believed."
I don't care what the theory says should happen; if the experimental evidence says something different, the theory is wrong. (Sometimes because it's based on bad CS, sometimes because it's based on faulty assumptions about how various classes actually do behave internally)
And be wary of relying on O() calculations when the relevant n is in your program really very small. It's also a mistake to calculate O() without taking into consideration the whole operating environment.
The best example I can think of here is using different List implementations as queues. If you just go blindly by a naive O() calculation, the LinkedList class is the obvious choice, but:
LinkedList does not exhibit O(1) behavior on queue operations for sufficiently large queues, and
Depending on environment, it takes a queue size of about 30 before its performance edges ahead of ArrayList
I investigated this closely after reading this article. Note that my first attempt at a CircularArrayList (implemented without first inspecting his code) ran about 10% slower than the code given in the article, though I gradually was able to tune it to comparable speeds.
The lesson from all of this is: "program performance should be treated as experimental science".
Why you might make some good theoretical points, some of your assumptions are off. I heartily recommend to you reading Sun's java manpage and searching for the word "default" before making statements about what the default behavior of java is.
By default java will limit the heap size to 64 MB If, as with most modern machines, you have significantly more than 64 MB to devote to user-mode applications, then the default settings will not in fact, as you contend, make performance horrible the instant more than one java application is launched. Also, keep in mind that with java, the JIT can if it wishes to do so move frequently accessed objects so that they are on adjacent pages of memory. This can dramatically reduce paging latency as compared to other code.
As for your points about L2 and L3 instruction caches - I suppose. At the very least, I don't know of any reason why it is obviously false. I'd need experimental confirmation first before I'd be willing to accept this.
If String class methods are showing up as the largest bottleneck, it's not concatenation that's doing it - unwise/unncessary concatenation causes StringBuffer., StringBuffer.append, and StringBuffer.toString to rise to the top in profile output.
Although I've never seen String class methods being a huge bottleneck, my initial guess is that somewhere you're ignoring the immutable nature of String and doing things similar to:
String s = new String("CONSTANT");
(and yes, I know that reflection lets you abuse Strings in unnatural ways - ignore that for now)
My suggestion would be to download hpjmeter or some similar tool for displaying the jdk's hprof output, generate cpu sampled hprof output, and look to see where you're calling these String methods that are bubbling to the top in the profiled output. For reference, we use the following command line when profiling our application:
And yes, that "synchronization isn't slow" bit is, in my experience, just wrong. Unless you've got some heavily CPU-bound process (or, possibly, are writing something involving user interaction) it's better to use as much non-blocking I/O as possible and stick to single threads whenever you can.
As I said elsewhere in this thread, all this says is that computer attacks are then like burglary, only with an even smaller chance of getting caught, and none of the danger of surprising someone at home and armed.
Which means, of course, that every now and then a blackhat might accidentally hit a target with unexpected resources; however, barring that, the only thing that can be done is publicity.
Obviously this guy has never had to deal with an actual, physical burglary. If he had, he would have realized:
The cops barely care about burglaries to begin with (it's low priority next to other things they have to do, and they're very difficult to solve anyway)
They care significantly less when there's no property that could be conceivably recovered. ("Someone broke into your apartment, and shredded your manuscript? That's tough.")
It sounds to me like the FBI was behaving perfectly sensibly, and prioritizing computer crime the way any police force would prioritize burglaries or vandalism: by dollar value. The essay says more about the life experience and mental state of the author than it does about the FBI's cybercrime response.
Re:Toward a bittorrent discovery protocol
on
BitTorrent Guide
·
· Score: 1
Could the mod_torrent pull the support information out of the request headers? Browser version or an indicator in the User Agent string would be a bit kludgy but might work.
Indeed, it would be kludgy, and completely unnecessary. See Section 14.39 of RFC 2616. A browser with support for a given encoding simply declares that it supports that encoding in the TE header of the request.
As for automatically creating torrent files, I think here's the order stuff needs to be worked on in order to implement this:
Talk to the bittorrent people to coordinate a standard "base url" extension to the bittorrent.torrent file. Actually, while we're at it, coordinating a standard "mime type" extension wouldn't be such a bad idea, either. For single file archives it doesn't matter much, but for multi-file archives, it's essential.
Float a proposal for a bittorrent Transfer-Encoding, and what that means. I would strongly suggest that what it means is that the server may return a bittorrent.torrent file which either describes how to download the single file asked for or describes an archive containing this file.
Write a first draft minimal apache mod_torrent which would only serve up manually created.torrent files that had been specifically configured in (in an.htaccess file, for example)
Write something in Mozilla that could start accepting these files. This is the hard part; I can't even tell if Mozilla allows this kind of thing to be done with plugins (the documentation is not clear; I think that plugins are only ever invoked for specific mime types). Unfortunately, if Mozilla does not allow for plugins that provide a new Transfer-Encoding, but only for those that handle a new Content-Type, then this effort is at least partially screwed. We'll have to jump to the ugly method of considering.torrent as an alternate Content-Type. (I suppose that one advantage of this is that in the early stages, we won't need an apache module and can instead rely on apache's content negotiation, along with manually created.torrent files)
Once all this is up and working, there can be discussion of automatically creating.torrent files. We really though need a browser implementation first.
Slashdot Mirror
Actually, that (taken from "A gentle introduction to Haskell"; cite those sources) is how I remember the basic algorithm.
And I find the four line version found on http://www.haskell.org/tutorial/goodies.html much more readable myself, but I tend to prefer short lines.
So some spammers have figured out string manipulation.
Are you serious? When I think "programming newbie", I think of someone who is having difficulty realizing that instructions are executed sequentially, one after the other, and that a variable's value will disappear if you overwrite it.[*] I remember getting very frustrated trying to explain to one of my college roommates how the value of a variable could change over time. (The model of a variable as a box that holds a value, and not merely a placeholder for a value, is not always as easy to explain as you might think; he was a bit confused that "a := a + 1" didn't cause an infinite loop)
And you want to burden these people with a java environment? With a language that doesn't even have an interactive toplevel?
The read-eval loop that my first basic (on the TI/99 4A) started up with was something I never really appreciated until I watched someone else trying to learn to program purely through writing programs and compiling them. The mind really needs to have a chance to use and experiment with a concept to get it to sink in. For the fundamental concepts behind most programming languages, I really feel that this mandates an interactive toplevel; this is something no java environment I've ever seen offers. (As an aside: is there a nice beanshell plugin for Eclipse?)
This applies both to those learning to program on their own and to those learning as part of a formal class. Trying to learn the basics of programming without an interactive toplevel is a bit like trying to learn how to drive without ever walking first - you'd get so caught up in shifting gears and pushing pedals that you'd never get to figure out basic concepts like not getting lost when you can't see the house anymore.
[*] Yeah, yeah, some languages have control flow that doesn't follow this model, but I've never heard any of those proposed as first computer languages either. (Though I do think that my roommate might have done better starting out in Haskell than Pascal)
This is, so far as I can tell, standard industry practice in certain places, and I'll tell you the result: everything gets tunnelled over HTTP.
When people have some brand new protocol (say, when Microsoft was developing SOAP), they'll make it so that it tunnels over HTTP. When some random company designs the protocol that their new data appliance uses to call home for updates and instructions, they'll tunnel it over HTTP. Eventually, every possible bit of functionality will be tunnelled over HTTP. Those trying to secure the network will have gained nothing except extra bandwidth and protocol overhead.
Face it guys - you're shooting yourselves in the foot here over the long term. When employees with the purchasing power and authority to place a machine on the network cannot get the network administrators to open up necessary port access (and if it's too much of a hassle to deal with the network security guys, then that's just as bad), you have the situation where network security will be circumvented.
Network security only exists with the active cooperation of informed employees; pretending that it's a purely technical problem that fancy network hardware can solve is just wishful thinking.
Squeak is a cross-platform implementation of smalltalk that has developed quite the little community of educators and students around it. It allows budding programmers to start on a very basic level - something reminiscent of hypercard - but underneath it all is a real language that allows all the power and syntax you might want. As soon as you're ready, the power is there.
The scheme environment bundled with How To Design Programs has a similar goal of allowing the student to gradually ramp up the complexity of the language, but I find their rigid levels confining. Also, the programs a beginning programmer is able to put together are nowhere near as satisfying visually as what a new squeak user can build. (These kids today - in my day, we had either text or 40 by 40 graphics and we liked it.) That said, the htdp scheme environment may be more appropriate for a structured classroom environment with a series of lessons.
My only complaint about squeak is the license (despite claims on squeak.org, it's not really an open source license because of the fonts it includes); however, it is free-as-in-beer and has been already been used in elementary and middle school classrooms for both teacher- and student-created projects. (See squeakland)
There's NOTHING wrong with being taught something for its own sake.
Actually, I'd say that there is. There's nothing wrong with learning a subject for its own sake or with studying a subject for its own sake.
However, "being taught" is something entirely different. (hint: it's passive voice; who's the actor?) I'll not argue the point much further (I've actually got other things to do than slashdot), but rather just point you to this wiki entry and encourage you to read the results of a a google search on "unschooling".
But seriously, what do these two stories have to do with each other, other than that they probably both belong in the "Your Rights Online" section?
The key to getting PNG to work properly with Internet explorer is to flatten your image down to 256 colors (indexed). This also allows only single-bit transparency.
This is what I did with my user image for livejournal. Sure, it's not as nice as full 24-bit transparency, but it's everything you were able to get with (non-animated) GIFs, except with smaller files. (And, unlike most GIF usage, legal without buying a license)
Doing this to an image inside GIMP is pretty simple: Image->Mode->Indexed.
There's also the bizarre CSS3 trick mentioned in other comments to this article; I haven't tried that yet.
Minor correction:
Contravariance means that you can unpack a Base from a list of Derived without casting.
- Rapid development. For anything (like a P2P app) where the value increases mostly through network effects (how many other people are using the same product), translating ideas into working code is critically important.
- Built-in, conveniently accessed hashes. (aka associative arrays) I program in java regularly, and it's a much bigger pain using a
.get() call for every damn dictionary access than the same code in python. (or perl, for that matter) Any piece of syntax that gets in the way of seeing the forest for all the damn tree leftovers cluttering up your view should be eliminated.
- Cross-platform independence.
As to your objections to python, I find them bizarre. Perhaps on the tracker of a very busy download the CPU speed/memory usage is significant, (witness his statement that several alternative trackers are being worked on) but in any client the entire process is completely network IO bound. As for the problems with Python's garbage collector - BitTorrent (well, the code of it that I've looked at so far) doesn't use recursive structures, so I don't see what the objection is there.Also, "awkward approach towards object creation/destruction"? What exactly does Python do that you wish it didn't? It sounds to me like you're pining for the days before people realized that object destruction costs, and that therefore it's best left to a garbage collector that can operate at idle times.
Furthermore, there's nothing that says you can't be fairly compensated for your time in putting the source on CD and mailing it (just be sure to obey clause 3b of the GPL - you can't include the administrative overhead of keeping track of the source in your cost for producing a source CD)
.iso's of the GPLed source that went into each release of the product - you do have everything under version control, right? - and stick them somewhere in permanent storage. You don't have to go nuts here, making sure that the iso is nicely structured or anything. Just put the source to the GPL'd parts in whatever format you already have it on the CD. No one says that you have to carefully think through UI considerations in your GPL section 3b compliance.
Were I an embedded developer, here's what I'd do:
1) Read the GPL. It's not that long, and as license go is very, very readable.
2) Place a "GPL compliance" notice in the printed documentation (along with any other required compliance notices, like FCC or other legal notices) that says something like: "Some of the source code used in FOOPRODUCT is covered under the Gnu General Public License (Gnu GPL). Persuant to the terms of that license, FOOCOMPANY will supply the relevant source code on demand for three years from the date this product was sold. Send inquiries to gplcompliance@foocompany.com and refer to FOOPRODUCT build number 123456a." (or "refer to the model number stamped on the bottom of the unit")
When I first bought my first linux CD from LSL, they printed the required GPL notice around the edge on the top of the CD. You could probably shorten the notice a bit, too, and get it down to something that could easily be put on a disklabel.
Then, set up an autoresponder at that address that says "here's what a CD of the GPL'ed source costs for us to copy, here's how much we'll charge you for shipping and handling, here's who to contact to actually order the source".
Then, I'd prepare
If it's part of the regular process for releasing a version of the product, (and archiving all the source somewhere permanent should be part of that regular process anyway) we're not talking about much additional overhead at all.
What torrent extensions would be necessary to support this?
.torrent extensions have been proposed? Which of these are viable?
I'm thinking adding a base URI field and a mime-type field would be necessary, but I'd like to know what thought he's given to this.
What
Actually, the grandparent post suggests the first viable attack on this that I've seen suggested here - the other attacks (network tricks, etc.) rely on Phoenix's BIOS designers being so amazingly technically incompetent that they wouldn't cryptographically sign the "kill yourself" message.
This attack, however, relies only on a single instance of minor social incompetence by a call-desk employee. Attacks like this have already been shown to work on large corporations who are supposedly in the business of verifying identity - remember when VeriSign handed out two certificates for "Microsoft Corporation" to people who just asked for them?
The disadvantage of this attack is that it would in all likelihood be relatively easy to trace who had done it - it's highly unlikely that Phoenix's call center would accept a "my laptop's been stolen" call from a pay phone, and their procedures may even call for confirming any theft report by calling the supposed rightful owner back.
However, depending on the relationship between Phoenix and the major OEMs, the attack may get easier - it may be much easier to get Phoenix to think that I'm a Dell call-center employee reporting the theft of Mr. BigWig's laptop than to convince Phoenix that I'm Mr. BigWig or his authorized representative. That's something we'll have to wait and see on - it all depends on how the social network between Phoenix and the large OEMs are designed.
I'm certain that there's no one thinking up a technical attack here on slashdot that's viable against this system in the field. However, I have a reasonable expectation of incompetence from large corporations when it comes to designing the social network half of this system.
A language neutral course like, say, Information Extraction, is not without implementation - the students still have several projects to implement and can't merely do pencil-and-paper work. However, the focus is not on which language is used, but rather on what the results of the program are. In other words, the implementation is not critiqued or dealt with in the course except in terms of the external results.
For example, in the one graduate-level computer course I took (I was a math major; CS was just for fun), we were explicitly told by the professor to implement our projects in "whatever language you want". And we did; I was somewhat boring with my choices of C for the number crunching and perl for turning the numbers into nice summary reports, but several people used java, there was a dedicated group of matlab people, and one guy did almost everything in scheme. Supposedly, someone also implemented the first project as about 10 different interacting sh scripts and GNU expr, but I think that was just exaggerated rumor.
If the requirements for the assignments had specifically included performance, you probably would have seen less variation (at least the shell script tricks would have been out), but in this class they didn't happen to. The resulting language choice was a result of students needing to get the job done, not professorial fiat.
The point is, once you get to graduate level work, (as the grandparent post was talking about) the language itself is just a tool with which to study other aspects of computer behavior. (Unless, of course, you're explicitly studying the possibilities of computer languages themselves) Of course the university (in Canada, "university" means almost exclusively graduate work, unlike here in the US) doesn't teach C - it shouldn't really be teaching any specific language except possibly as an example of what a certain language family looks like.
This only applies if you don't provide the source at the time that you provide the binaries. If you do that, you're off the hook (even if the person you gave the source to throws it away - they might be unable to give the software to someone else, but you are off the hook).
I remember when I first ordered a Debian CD from LSL - they had the GPL-required "will provide source" written offer written around the edge of the CD.
This industry is a sham the more I look into it.
Aside from the fact that I don't know quite why this rant got attached to parent post it did, of course the industry looks like a sham when you look at it from where you are. Any white collar work looks like a sham until you've been around it long enough to either find the parts that honestly aren't a sham or have cognitive dissonance kick in. It's just the nature of the US job market - the market is not a moral engine, and expecting it to act as one is just a recipe for disillusion.
As for the 'morons' problem - the problem isn't really with people who are grossly incompetent. Those actually can be weeded out in job interviews or fired later without too much trouble. The problem is with people who, once you really get to know them outside an interview, no longer appear good enough to have hired, but are too good to go through what's necessary to fire them. The end result is that they float by, sometimes even being promoted so as to get them out of the way. (Though in all honesty, there are occasionally "just good enough" programmers who turn out to be tolerable or even good managers or customer representatives)
Now, because HR actually does get wind of this problem, they attempt to respond by hiring better people. Unfortunately, they don't really know how to filter out people who are "just barely good enough", so they respond the only way they know how (up the number of years required, up the academic requirements). Yes, it sucks, but it arguably isn't even their fault, since it's really very hard in a job interview setting to tell the difference between a good programmer and a "just good enough" programmer.
A month ago I was talking to a former coworker who is now with a small start-up as their lead programmer about the pain he was going through hiring new people. They have had to go to a system of one-week "trial hires" - after a good interview, they agree to pay you for one week and give you one assignment that should only take that long. If you can do it, and do it well, you're hired. If not, they're only out one week's worth of pay.
They were starting this system after having to let three different employees go each after about 8 weeks when it became clear that they weren't actually up to the level the company needed, despite getting past an interview that should have cleared out technical incompetency.
I don't know how that system's worked out for them in the long run since they had just started it when last I talked to him.
actualy wanted to use them. Talk about dupes.
And what the other respondent said about the sig; I hadn't heard that anywhere before.
What exactly is the point of this regulation?
Do they also ban ZIP drives and floppies?
I can understand this ban only in a few specific industries that also run with very restrictive internet filtering; are you in one of those?
Sure you do, if you try to access them without first calling setAccessible .
However, it's pretty easy to turn that exception off unless there's a SecurityManager installed.
Conclusion? Don't make any java code a security boundary without putting a SecurityManager properly in place. This also implies that java code at security boundaries has trouble being fast, but that's the case with any code at security boundaries.
I'd revise this statement to: "if you don't have some sort of evidence (experimental or hard theoretical) backing to your claim that one method is faster than another, your claim can't be believed."
I don't care what the theory says should happen; if the experimental evidence says something different, the theory is wrong. (Sometimes because it's based on bad CS, sometimes because it's based on faulty assumptions about how various classes actually do behave internally)
And be wary of relying on O() calculations when the relevant n is in your program really very small. It's also a mistake to calculate O() without taking into consideration the whole operating environment.
The best example I can think of here is using different List implementations as queues. If you just go blindly by a naive O() calculation, the LinkedList class is the obvious choice, but:
I investigated this closely after reading this article. Note that my first attempt at a CircularArrayList (implemented without first inspecting his code) ran about 10% slower than the code given in the article, though I gradually was able to tune it to comparable speeds.
The lesson from all of this is: "program performance should be treated as experimental science".
Why you might make some good theoretical points, some of your assumptions are off. I heartily recommend to you reading Sun's java manpage and searching for the word "default" before making statements about what the default behavior of java is.
By default java will limit the heap size to 64 MB If, as with most modern machines, you have significantly more than 64 MB to devote to user-mode applications, then the default settings will not in fact, as you contend, make performance horrible the instant more than one java application is launched. Also, keep in mind that with java, the JIT can if it wishes to do so move frequently accessed objects so that they are on adjacent pages of memory. This can dramatically reduce paging latency as compared to other code.
As for your points about L2 and L3 instruction caches - I suppose. At the very least, I don't know of any reason why it is obviously false. I'd need experimental confirmation first before I'd be willing to accept this.
Although I've never seen String class methods being a huge bottleneck, my initial guess is that somewhere you're ignoring the immutable nature of String and doing things similar to:(and yes, I know that reflection lets you abuse Strings in unnatural ways - ignore that for now)
My suggestion would be to download hpjmeter or some similar tool for displaying the jdk's hprof output, generate cpu sampled hprof output, and look to see where you're calling these String methods that are bubbling to the top in the profiled output. For reference, we use the following command line when profiling our application:And yes, that "synchronization isn't slow" bit is, in my experience, just wrong. Unless you've got some heavily CPU-bound process (or, possibly, are writing something involving user interaction) it's better to use as much non-blocking I/O as possible and stick to single threads whenever you can.
As I said elsewhere in this thread, all this says is that computer attacks are then like burglary, only with an even smaller chance of getting caught, and none of the danger of surprising someone at home and armed.
Which means, of course, that every now and then a blackhat might accidentally hit a target with unexpected resources; however, barring that, the only thing that can be done is publicity.
It sounds to me like the FBI was behaving perfectly sensibly, and prioritizing computer crime the way any police force would prioritize burglaries or vandalism: by dollar value. The essay says more about the life experience and mental state of the author than it does about the FBI's cybercrime response.
Indeed, it would be kludgy, and completely unnecessary. See Section 14.39 of RFC 2616. A browser with support for a given encoding simply declares that it supports that encoding in the TE header of the request.
As for automatically creating torrent files, I think here's the order stuff needs to be worked on in order to implement this:
Once all this is up and working, there can be discussion of automatically creating