Re:Irrelevant? Absolutely. I kicked the habit!
on
Is 3G Irrelevant?
·
· Score: 1
I always kept it on vibrate, so it _never_ rang out loud. I also turned off the power when I absolutely could not be disturbed, ie. watching a movie or during important meetings. Still, I found having a cell phone was more a drag on my life than an aid. So they're history. I'm pretty happy with the results.
Irrelevant? Absolutely. I kicked the habit!
on
Is 3G Irrelevant?
·
· Score: 3, Insightful
About six months ago, I cancelled my two cell phones and decided to "rough it" for a while, saving money in the meantime. I haven't looked back. I never get rings in the middle of the night asking me to come in to work, never get the spousal unit 'checking up on me' periodically throughout the day and ruining my concentration, and I no longer have to answer tech support calls for my entire family whenever they can't get Windows to print a frickin' greeting card.
So, yes, 3G is irrelevant, unless you're tied to your cell phone like a dog to its master. <grin>
I found out through several hours of talking to morons at the help desk of Cingular Wireless (Texas area split off from Southwestern Bell) that SMS messages are sent via email addresses through a central server system. They don't even run it--they simply contract for their numbers to be funneled through the system--so Cingular couldn't even add features (or remove them, in my case).
I asked them to block all SMS to my phone, because I never used it and knew nobody would use it to contact me. They denied me three times, and eventually I wound up speaking with an engineer who had "never thought of" sending spam through an automated script to a block of easy to guess email addresses at a known server with public accessibility and no password protection for connections. Duh.
He then proceeded to inform me that all phones get firmware upgrades and such via SMS, and that's impossible to shut off or your service would terminate. So, until they start building whitelist filtering to each phone, you can't do jack shit about it.
I'm not surprised. Cursive writing was for people in a hurry. Now we have a better method. And now the so-called Master Penmen are upset that their little hobby will be archived next to the hurricane oil lamp and the carrier pidgeon. I bet the society of telegraph engineers were very upset about the telephone as well, but there's still a few out there using it.
What is this with forcing them to open what they have done to the world? It is not forcing anyone, it is just a license which the programmer choose to distribute his software under, or he choose not to, I can't see how that is forcing anything on anyone.
Do you know how to read? Try reading the GPL. It requires any derivative works to also be GPL. That's a restriction, because it means you can never make software that is available for sale from anything that has been opened as GPL. Pretty serious restriction, if you ask a professional programmer. I am one, I know.
As a result, the GPL has proven itself to be an excellent source for back-office proprietary, offline tools that never see the light of day and are never intended for release to the public in any form. Then you don't have to provide source code, and lose nothing of your technological edge to your competitors.
While I admire the spirit of GNU, they're very impractical, and cause tremendous heartache among programmers that are generally in favor of their movement than not. Unfortunately, its primary target, the packaged software industry, is largely unscatched.
...to buy a typical box-fan of the 3'x3' variety at your local WalMart, go to the air conditioning section and buy a 3'x3' inexpensive pleated filter (or two, as filtration is directly related to the square footage of the filter media) and tape one or more in series onto the intake side of the fan. The more filters you put on, the cleaner the air will get, to a point. If you're really nuts, put a HEPA nearest the fan and lower density filters further out, to reduce clogging on the HEPA. Electrostatic filters can work similarly, but require monthly cleansing and re-spraying to add an ionizing charge to the filter.
This is pretty darn inexpensive, even if you count the cost of duct tape. It's guaranteed to clean the heck out of a room, and you can just glance at it occasionally to know if it's dirty.
If you're extremely paranoid about microbes too, you can buy a UV light and hook it to the outgoing side and a shield to block UV leakage into the room--UV will kill anything that gets through the filters. UV lights can run a hundred bucks or so, but is still well under your $500 mark.
That said, real computer labs like those in Motorola's IS department, use laminar flow and raised flooring to force air upward and pull it out through the ceiling, to prevent settling and clogging. Their setups were fantastic for keeping the dust clear even with cramped quarters. That's definitely the expensive way to go, but the best.
I've been tested to have reactions to about 2/3 of the standard tests (I live in Austin, mold and pollen capital of the world--yay!), and this cheap filter has made a real difference with my asthma. Oh yeah, we moved into a house with no carpet--just tile and wood floors.
Graham makes a lot of noise, but in the end withers away in his LISP-oriented madness. I think he misses the boat in a serious way when he says parallelism is a dead end, and that it'll always be a feature utilized explicitly by the programmer. I was hoping to see the article talk about the future, but instead all I saw was a guy mumbling about the past and present. Here's my take on the future, really casting out there:
For a LISP programmer to say that is unthinkable. That's one of the major reasons LISP was useful, because it is a functional language, and as such can be automatically farmed out to multiple processors. Several companies were formed back in the 70's around that concept.
The problem is, functional languages have tended to be very stodgy, very limited, and awkward to use (see Lots of Irritating, Stupid Parenthesis) for non-mathematicians. Programming is increasingly done by lesser educated people... fewer and fewer of whom even have a CS degree. This trend will continue.
I predict that in 50 years, the dominant language will be a design language that is largely a dataflow description. A person describes where to receive the data (web, ftp, file on disk, from the output of another function somewhere), what kind of processing or manipulation to perform in somewhat general terms*, and that's it. *General terms means in terms of previously-defined operations. After a number of years, the libraries will be so rich and specialized that a user will not call a function by name, but instead describe in general terms what kinds of operations to do, the compiler picks several that sort of match, rank them in order, and use all of them in parallel, effectively forking the program for each different path it takes.
By the end of a program, there will be trillions of possible ways it would run. A few will be correct. The user will then have the arduous task of weeding out those which do not match expectations, by looking at the outcome and selecting them. The compiler will help by grouping results by similarity, and automatically rejecting obvious failures (divide by zeros, etc).
Additionally, the compiler is the runtime environment. This is where parallelism comes in, initially. Later, when a few working prototypes exist--it may be difficult or impossible to distinguish between some versions immediately--the compiler does all the optimization for the user. The longer it runs, the more structures it identifies and changes the internal representation of, and changes algorithms, and so on, until it tweaks the performance to an ideal state. This already happens today with certain tools, but on a very limited instruction-reordering scale. The scope of such code rewriting will increase dramatically as the language for describing operations becomes more abstract and less strictly tied to individual blocks of code. It will effectively use genetic algorithm techniques to determine the best execution rate and the user need not be involved.
The compiler/environment also naturally distributes its work across multiple processors, multiple pools of memory, and mulitple external storage devices. It knows how to connect up to trusted machines and devices (similar to how Bluetooth already works, but different medium), and distributes to those as well. As the article states, the core of the environment can be extremely simple, with all the advanced functions being implemented in terms of that basic core. Porting the core should be an hour's work, at most--that's how thin it would need to be. Thus, future computation would be capable of effectively leveraging large grids with practically no user involvement, and could extend or be carried around by portable wireless devices, or live in enclosed LANs, or whatever, without having the program care.
So, to further disagree with the article, I would see it as a convergence of LISP, Java, C++, and Visio. It would take (most of) the functional aspects of LISP, the intelligent enviro
Remember, you're not seeing the 100 year old houses that were poorly built, because they aren't there anymore
Been to East Texas lately? 100+ year old houses are all over the place, like gnats blighting the landscape. People buy them for $15,000 usually with the agreement that you lift it off the land and carry it away... Old Victorian homes are a different matter entirely. But 100 year old junk homes are all over the place. Just not in big cities, because the cities bulldozed all the poor folks homes, where the rich folk could afford to stay.
The way this sounds, there was a web page accessible to the internet that you could look up some information about 'yourself' by entering 'your' student ID #. If the person who wrote a script to harvest information stole 55,000 records, do they define theft to mean any access that is not using your own SSN? That's very much akin to having a bucket of mints next to the cash register at a restaurant... you generally take one on the way out, but some people take three or four. Or 55,000. Free within limits? Social customs do not apply on the internet.
Whoever the script kiddie was, he deserves an accolade for a dumb, brute force attack. Had he made one query an hour, we'd never know about the security breach and there'd be no warning about all the identity theft, and the system would go unfixed....And whoever wrote that web page should be held responsible for the attack. He may as well have opened the vault at Fort Knox and held a bank robber convention on the grounds.
In fact, the best way to get a un-chipped, modded XBox is to find a game whose save games have a buffer overrun in them, and exploit that. Simply transferring that save game to a friend's machine, running that (retail) game on their box and loading a save game could flash their machine.
The question is, what game has a buffer overrun, and where?
For those of you who don't follow the XBox modchip underground, the onboard TSOP can be flashed with a modchip's bios. The reason you need a modchip is because without a modchip, the XBox refuses to run an unsigned executable. With a signed version of Linux, you have an open system and can easily flash the onboard TSOP with a version that ignores digital signatures the same way a modchip would. Hence, an MS-signed Linux on a disc is effectively a modchip. Would it ever make sense for MS to do this? Absolutely not.
And all the crying about their monopoly is silly. Hardware vendors have restricted software that can run on their hardware for eons. It's largely for quality control reasons, but Nintendo and Sony have long killed projects after seeing distasteful material. "Thrill Kill", anyone? It's the way the industry works. Anything else and you'd see a total collapse of the console industry--not merely Microsoft's interest in it.
An Austin, Texas, man has filed a lawsuit against his employer, essentially claiming that showing up for work is not a viable model for increasing wealth rapidly. Prosecution recommends an immediate donation of $10 from all businesses in the metropolitan area into his private account, because it's just better that way.:-/
While I'm not a grammar fascist, I am irritated by the uncommon usage of she in contexts where clearly the accepted use of the word 'he' applies. The worst offenders are typically baby raising books, the section where I presume the most liberal authors hang out. They literally switch pronouns every few sentences, just to see if you're paying attention. They're unfuckingreadable. I use them for kindling now.
Technical papers should steer clear of using gender pronouns entirely, instead choosing 'the programmer' or 'the user', or avoiding them entirely. At least, that's what I've been instructed to do when writing documentation.
The problem with changing SMTP is that it's well-established and generally a good protocol. The problem with changing the default configuration for installation is it only affects new installations. Basically anything you propose which requires changes on the server, requires operators to agree. No strategy as such will work, unless operators are not given a choice, because their customers demand the upgrade.
I'd propose a slight change to SMTP servers so that they automatically block incoming mail from other servers that act as an open relay. It would not discriminate against open relays when sending mail, however.
What this does is effectively drops all users of open relays off the map. Once enough servers out there start doing this, all the open relays start getting fixed, because their users demand mail to stop bouncing. Open relay spam ceases to annoy everybody behind a protected server immediately, however, and you don't really care when or if those servers get fixed.
This isn't going to fix the general spam problem, where valid addresses are used for spam, but at least you can block domains that annoy you.
But the truth is, spam will never calm down until every unsolicited/untrusted message costs a nominal sum, which curteous people return in the form of a reply from valid messages.
I never claimed it would be 100%. Notice I specifically referenced the halting problem... Typical usage would benefit tremendously from such a feature, much of which is already known to the compiler. The last 1% of cases are for academics to bicker over. I'm a programmer, dammit.:-)
Another feature that I really wanted to see would be a popup that tells you what O() order a function call would be, and have the compiler determine it based on analysis and corrective comments for difficult functions. Again, the halting problem applies here, but it would move a certain type of documentation into the face of a programmer, rather than obscurely in the middle of several nested functions.
The pre/post-condition validation at write time is an idea I've been toying with for the past two years. The problem is that (most) languages do not extend pre- and post-conditions into the language itself. Rather, you have to infer them based on types. This isn't strong enough. What you really need is a language that allows you to define not only the types, but the values or ranges that are legal as input and legal as output.
So, what I did was started from there and modified the grammar of C++ until it met all my requirements, then removed some things that would make such analysis impossible (like pointer arithmetic and anything else that contributes to weak typing), then added a few tweaks that I always wanted in my own language.
The result? An almost purely functional language, using C++ like syntax, with some unique features... for instance, one of my favorites was that scoping with braces { } works differently, such that you must declare all variables you take _into_ scope from the parent block, and you could poke locally declared variables _out_ of that scope into the parent block through another declaration. This follows exactly the same syntax as declaring a function, which made it trivial to rearrange blocks of code or inline things manually, etcetera. It also solves the problem of scope reduction for temporaries which are used only to call the constructor on a non-default constructor class.
Alas, I have no time to write the language, and considerably less to write an analysis tool like you describe, but it would have been neat to play with. A nearly perfectly functional language, as you know, parallelizes really well so I'd planned to put it on a cluster. Even bought the machines for it, then sold them when my interest waned.:-)
I didn't get a close look at the article, so I can't say if it's a CRC16 or CRC32. Assuming a CRC32, the probability of a one-bit error making it through undetected is 1/2 ^ 32, or highly likely to be caught. However, multi-bit errors (from what I recall reading on CRC's recently) are _more_ likely to be caught. I can't locate a souce on that at the moment, but there are some interesting sources here that might prove fruitful.
Due to the nature of CRC, each successive bit radically changes the sum, so that single bit errors are easy to detect, and multi-bit errors are even easier, IIRC.
If they're going to take up storage real estate on a hard drive where you own the platters, but you can't use the data legally, they owe you compensation for the space they're stealing from you.
In short, charge them a monthly fee for having their data on your hard disk drive. Many companies do that as their primary business--selling external storage.
The sooner such practices as this bankrupt the businesses at fault, the sooner the practices go away.
There's a huge difference between a programmer and an analyst, as you describe it. Programmers create an eternal product, that is source code that solves a particular problem. Often, problems are recurrent and the same solution will work in an infinite number of cases. If you have access to the source code, it can be adapted to meet the changes in problem parameters. Some programmers can make it their life's work to maintain a single solution-giving set of source code, and get paid well to do so.
Analysis of a problem doesn't solve anything directly, so you work in a service-oriented field. It's information to be used or not used, but at the end of the day, you haven't solved the problem being analyzed. They might hire 20 analysts (wastefully) to provide insight or estimates, and they might all disagree, and they won't have solved the problem. However, after a programming team does their work, the problem is solved now and forever. Programmers are content/solution producers. Analysts are not.
I'm not judging either field. I'm simply stating that your analogy and your plea for "A Day's Pay For A Day's Work" is meaningful ONLY in a service oriented profession. Otherwise, you'd have musicians that could never get paid more than once for making a recording, and authors that would always get paid one time for a book, or programmers that could never sell the same software several times. Do you see the difference?
After hearing about how great a book this was for months after its initial release--from both good and bad programmers--I thought it would be worth looking into. So I picked up a copy and flipped through it, mainly hitting the patterns themselves.
What I found was there were a lot of abstract design ideas that now have names, which I suppose is a good thing. I was dissatisfied, however, with the quality of the content. A lot of the patterns were bad designs, and I didn't see any admonitions like 'you should never use this except in this very narrow case XYZ, where you don't have any control over the code to redesign it properly (3rd party libs) and it must exhibit ABC properties', but should have been. Just presenting designs with names is like loading a gun with multicolored bullets and handing it to a child.
After discussing the book with many co-workers, I noticed the trend that the programmers who tended to be more methodical and thorough in their up-front design, disliked the book, because it gave them no new ideas to work with, and introduced a number of useless designs on equal footing with the good ones. However, the programmers that were most scatterbrained and tended to play fast and loose with OOD and data flow, loved the book because it gave them a definitive reference for what to call the messes they create, without making judgements on their codepiles.
I'm not saying that it's a bad book, but I am saying it appeals to a crowd that needs that kind of book. Unfortunately, no book can teach Good Design. That author would be rich indeed.
I spent a couple of weeks tinkering with the idea a while back and wrote a server script in Perl that can run on any Win32 box (no compilers or anything necessary to be installed), and wrote a client script that plugs into MSVC++'s IDE. The client parses the build commands and contacts all servers through a UDP broadcast, then connects to each server, preprocesses a file at a time, transfers the processed C/C++ file and the compiler and its related binaries to the server, then sends the build commands to the server as well. All output is captured on the server and sent back to the client.
It worked pretty well, except I had a lot of problems getting fork to work right in Perl on my Win32 box without crashing, so I could get good parallelism. It even fell back to using the local machine in the event of a failure remotely at any point, so on a multiprocessor development machine and no servers to connect to, it would actually use all the processors to compile--something MSVC doesn't do normally.
The nice thing about the server script is it only has three functions: accept a file, send a requested file, and execute an arbitrary command. So it doesn't really care about what it's doing. At work, we're planning to use it to leech some cycles off the receptionist machines and managers' boxen (we all know they don't do anything all day but email anyway!).
The real limiting factor is that preprocessing is relatively slow due to seeks on the hard drive, where not all the headers fit in the disk cache at once. This is a bigger bottleneck than you'd believe.
For what it's worth, I've learned of another company that concatenated all their.cpp files together and only compiled that one file every time, so their build was a fixed (short) cost, and never hit any header twice. Dirty code that has module-local statics would choke on that technique, but for good code, it's prolly smarter than distributing it.
Hardware page size is 4KB, as was noted elsewhere. The key element that I haven't seen mentioned is that Windows' virtual memory system has several ways to 'allocate' memory. There's reserving pages, and there's committing pages. In the case where you tell the OS you want memory, it reserves pages. That is to say, it does not actually take memory from the free physical memory, but instead creates a contiguous address space large enough for your request, but allocates no hardware RAM at those addresses.
When you commit a page, either through accessing a page (read or write) that is not allocated, it trips a hardware fault if the VM hasn't mapped a page to the address, which then searches for a free page, then links them together.
The end result is, even if Windows does try to create 64k worth of memory segment space for a process, unless it is actually reading or writing to a byte in each 4k chunk, its internal VM will not allocate physical memory for the whole 64k. Furthermore, there's no such advantage or realistic way for the operating system to align anything in memory physically, except in AGP ram. The VM system handles physical pages of memory exclusively, but does not manage AGP-allocated memory (IIRC). In other words, though the OS can align the address space to anything it likes, the OS layer cannot request any physical allocation mapping or alignment. So that comment about aligning memory for processes is quite unlikely.
Now, the XBox (which runs a variant of the Win2k kernel) has a bit more control over VM, but it also does not support demand paging, so it cannot swap to the hard disk and give you RAM+HD effective memory. Shame, that. But, as a result, you have an API that allows hardware level allocation control. Still, the OS doesn't take advantage of it, AFAIK. It's for developers.
It's important to ask yourself first, What does this piece of software do? Then, how far down the list of features that are important for it achieving that goal will you find Does it work with competing CMS's? Probably at the bottom, just below Can I use it as a text editor?:-)
As long as the CMS is stable and their formats are open, anyone can come along and write a bridge that lets them work together in a minimal sense. Asking for total interoperability is looking for total convergence of features, which is the long way of asking for only one system with slightly different interfaces.
My opinion, which only matters to me, is that each different system grew up because of a shortcoming of another, as applied to a particular situation. Making them interoperate may be impossible without losing those advantages.
Who signs the certificate? I don't want to pay Verisign $200/year just so I can send email. I certainly don't want more spam from Waitrose just because they paid Verisign $200 for a certificate.
Thawte does. For free. As far as I remember, it's an automated system that requires a good deal of info to generate a certificate, and has a higher privilege certificate for people who have been independently stamped, probably like the PGP/GPG web of trust.
The point isn't to make a whitelist, but to exclude anyone who doesn't use a certificate. It would probably then be an ISP service to give you a certificate with every account signup (or let you get your own, or use your previous one if you have one already), so it would be significantly less a barrier to entry for new users. I think it would raise the stakes significantly for spammers, especially since forging a certificate is a legal offense, since signed documents are admissible as evidence, IIRC.
Slashdot Mirror
(next)
This is my
(next)
story about how
(next)
I thought I was a
(next)
Real Man for hiring
(next)
a contractor to do my
(next)
manly work. Call me 404.
I always kept it on vibrate, so it _never_ rang out loud. I also turned off the power when I absolutely could not be disturbed, ie. watching a movie or during important meetings. Still, I found having a cell phone was more a drag on my life than an aid. So they're history. I'm pretty happy with the results.
About six months ago, I cancelled my two cell phones and decided to "rough it" for a while, saving money in the meantime. I haven't looked back. I never get rings in the middle of the night asking me to come in to work, never get the spousal unit 'checking up on me' periodically throughout the day and ruining my concentration, and I no longer have to answer tech support calls for my entire family whenever they can't get Windows to print a frickin' greeting card.
So, yes, 3G is irrelevant, unless you're tied to your cell phone like a dog to its master. <grin>
I found out through several hours of talking to morons at the help desk of Cingular Wireless (Texas area split off from Southwestern Bell) that SMS messages are sent via email addresses through a central server system. They don't even run it--they simply contract for their numbers to be funneled through the system--so Cingular couldn't even add features (or remove them, in my case).
I asked them to block all SMS to my phone, because I never used it and knew nobody would use it to contact me. They denied me three times, and eventually I wound up speaking with an engineer who had "never thought of" sending spam through an automated script to a block of easy to guess email addresses at a known server with public accessibility and no password protection for connections. Duh.
He then proceeded to inform me that all phones get firmware upgrades and such via SMS, and that's impossible to shut off or your service would terminate. So, until they start building whitelist filtering to each phone, you can't do jack shit about it.
I'm not surprised. Cursive writing was for people in a hurry. Now we have a better method. And now the so-called Master Penmen are upset that their little hobby will be archived next to the hurricane oil lamp and the carrier pidgeon. I bet the society of telegraph engineers were very upset about the telephone as well, but there's still a few out there using it.
What is this with forcing them to open what they have done to the world? It is not forcing anyone, it is just a license which the programmer choose to distribute his software under, or he choose not to, I can't see how that is forcing anything on anyone.
Do you know how to read? Try reading the GPL. It requires any derivative works to also be GPL. That's a restriction, because it means you can never make software that is available for sale from anything that has been opened as GPL. Pretty serious restriction, if you ask a professional programmer. I am one, I know.
As a result, the GPL has proven itself to be an excellent source for back-office proprietary, offline tools that never see the light of day and are never intended for release to the public in any form. Then you don't have to provide source code, and lose nothing of your technological edge to your competitors.
While I admire the spirit of GNU, they're very impractical, and cause tremendous heartache among programmers that are generally in favor of their movement than not. Unfortunately, its primary target, the packaged software industry, is largely unscatched.
...to buy a typical box-fan of the 3'x3' variety at your local WalMart, go to the air conditioning section and buy a 3'x3' inexpensive pleated filter (or two, as filtration is directly related to the square footage of the filter media) and tape one or more in series onto the intake side of the fan. The more filters you put on, the cleaner the air will get, to a point. If you're really nuts, put a HEPA nearest the fan and lower density filters further out, to reduce clogging on the HEPA. Electrostatic filters can work similarly, but require monthly cleansing and re-spraying to add an ionizing charge to the filter.
This is pretty darn inexpensive, even if you count the cost of duct tape. It's guaranteed to clean the heck out of a room, and you can just glance at it occasionally to know if it's dirty.
If you're extremely paranoid about microbes too, you can buy a UV light and hook it to the outgoing side and a shield to block UV leakage into the room--UV will kill anything that gets through the filters. UV lights can run a hundred bucks or so, but is still well under your $500 mark.
That said, real computer labs like those in Motorola's IS department, use laminar flow and raised flooring to force air upward and pull it out through the ceiling, to prevent settling and clogging. Their setups were fantastic for keeping the dust clear even with cramped quarters. That's definitely the expensive way to go, but the best.
I've been tested to have reactions to about 2/3 of the standard tests (I live in Austin, mold and pollen capital of the world--yay!), and this cheap filter has made a real difference with my asthma. Oh yeah, we moved into a house with no carpet--just tile and wood floors.
Graham makes a lot of noise, but in the end withers away in his LISP-oriented madness. I think he misses the boat in a serious way when he says parallelism is a dead end, and that it'll always be a feature utilized explicitly by the programmer. I was hoping to see the article talk about the future, but instead all I saw was a guy mumbling about the past and present. Here's my take on the future, really casting out there:
For a LISP programmer to say that is unthinkable. That's one of the major reasons LISP was useful, because it is a functional language, and as such can be automatically farmed out to multiple processors. Several companies were formed back in the 70's around that concept.
The problem is, functional languages have tended to be very stodgy, very limited, and awkward to use (see Lots of Irritating, Stupid Parenthesis) for non-mathematicians. Programming is increasingly done by lesser educated people... fewer and fewer of whom even have a CS degree. This trend will continue.
I predict that in 50 years, the dominant language will be a design language that is largely a dataflow description. A person describes where to receive the data (web, ftp, file on disk, from the output of another function somewhere), what kind of processing or manipulation to perform in somewhat general terms*, and that's it. *General terms means in terms of previously-defined operations. After a number of years, the libraries will be so rich and specialized that a user will not call a function by name, but instead describe in general terms what kinds of operations to do, the compiler picks several that sort of match, rank them in order, and use all of them in parallel, effectively forking the program for each different path it takes.
By the end of a program, there will be trillions of possible ways it would run. A few will be correct. The user will then have the arduous task of weeding out those which do not match expectations, by looking at the outcome and selecting them. The compiler will help by grouping results by similarity, and automatically rejecting obvious failures (divide by zeros, etc).
Additionally, the compiler is the runtime environment. This is where parallelism comes in, initially. Later, when a few working prototypes exist--it may be difficult or impossible to distinguish between some versions immediately--the compiler does all the optimization for the user. The longer it runs, the more structures it identifies and changes the internal representation of, and changes algorithms, and so on, until it tweaks the performance to an ideal state. This already happens today with certain tools, but on a very limited instruction-reordering scale. The scope of such code rewriting will increase dramatically as the language for describing operations becomes more abstract and less strictly tied to individual blocks of code. It will effectively use genetic algorithm techniques to determine the best execution rate and the user need not be involved.
The compiler/environment also naturally distributes its work across multiple processors, multiple pools of memory, and mulitple external storage devices. It knows how to connect up to trusted machines and devices (similar to how Bluetooth already works, but different medium), and distributes to those as well. As the article states, the core of the environment can be extremely simple, with all the advanced functions being implemented in terms of that basic core. Porting the core should be an hour's work, at most--that's how thin it would need to be. Thus, future computation would be capable of effectively leveraging large grids with practically no user involvement, and could extend or be carried around by portable wireless devices, or live in enclosed LANs, or whatever, without having the program care.
So, to further disagree with the article, I would see it as a convergence of LISP, Java, C++, and Visio. It would take (most of) the functional aspects of LISP, the intelligent enviro
Remember, you're not seeing the 100 year old houses that were poorly built, because they aren't there anymore
Been to East Texas lately? 100+ year old houses are all over the place, like gnats blighting the landscape. People buy them for $15,000 usually with the agreement that you lift it off the land and carry it away... Old Victorian homes are a different matter entirely. But 100 year old junk homes are all over the place. Just not in big cities, because the cities bulldozed all the poor folks homes, where the rich folk could afford to stay.
The way this sounds, there was a web page accessible to the internet that you could look up some information about 'yourself' by entering 'your' student ID #. If the person who wrote a script to harvest information stole 55,000 records, do they define theft to mean any access that is not using your own SSN? That's very much akin to having a bucket of mints next to the cash register at a restaurant... you generally take one on the way out, but some people take three or four. Or 55,000. Free within limits? Social customs do not apply on the internet.
...And whoever wrote that web page should be held responsible for the attack. He may as well have opened the vault at Fort Knox and held a bank robber convention on the grounds.
Whoever the script kiddie was, he deserves an accolade for a dumb, brute force attack. Had he made one query an hour, we'd never know about the security breach and there'd be no warning about all the identity theft, and the system would go unfixed.
Yes. Absolutely.
In fact, the best way to get a un-chipped, modded XBox is to find a game whose save games have a buffer overrun in them, and exploit that. Simply transferring that save game to a friend's machine, running that (retail) game on their box and loading a save game could flash their machine.
The question is, what game has a buffer overrun, and where?
JH
For those of you who don't follow the XBox modchip underground, the onboard TSOP can be flashed with a modchip's bios. The reason you need a modchip is because without a modchip, the XBox refuses to run an unsigned executable. With a signed version of Linux, you have an open system and can easily flash the onboard TSOP with a version that ignores digital signatures the same way a modchip would. Hence, an MS-signed Linux on a disc is effectively a modchip. Would it ever make sense for MS to do this? Absolutely not.
And all the crying about their monopoly is silly. Hardware vendors have restricted software that can run on their hardware for eons. It's largely for quality control reasons, but Nintendo and Sony have long killed projects after seeing distasteful material. "Thrill Kill", anyone? It's the way the industry works. Anything else and you'd see a total collapse of the console industry--not merely Microsoft's interest in it.
JH
An Austin, Texas, man has filed a lawsuit against his employer, essentially claiming that showing up for work is not a viable model for increasing wealth rapidly. Prosecution recommends an immediate donation of $10 from all businesses in the metropolitan area into his private account, because it's just better that way. :-/
While I'm not a grammar fascist, I am irritated by the uncommon usage of she in contexts where clearly the accepted use of the word 'he' applies. The worst offenders are typically baby raising books, the section where I presume the most liberal authors hang out. They literally switch pronouns every few sentences, just to see if you're paying attention. They're unfuckingreadable. I use them for kindling now.
Technical papers should steer clear of using gender pronouns entirely, instead choosing 'the programmer' or 'the user', or avoiding them entirely. At least, that's what I've been instructed to do when writing documentation.
The problem with changing SMTP is that it's well-established and generally a good protocol. The problem with changing the default configuration for installation is it only affects new installations. Basically anything you propose which requires changes on the server, requires operators to agree. No strategy as such will work, unless operators are not given a choice, because their customers demand the upgrade.
I'd propose a slight change to SMTP servers so that they automatically block incoming mail from other servers that act as an open relay. It would not discriminate against open relays when sending mail, however.
What this does is effectively drops all users of open relays off the map. Once enough servers out there start doing this, all the open relays start getting fixed, because their users demand mail to stop bouncing. Open relay spam ceases to annoy everybody behind a protected server immediately, however, and you don't really care when or if those servers get fixed.
This isn't going to fix the general spam problem, where valid addresses are used for spam, but at least you can block domains that annoy you.
But the truth is, spam will never calm down until every unsolicited/untrusted message costs a nominal sum, which curteous people return in the form of a reply from valid messages.
I never claimed it would be 100%. Notice I specifically referenced the halting problem... Typical usage would benefit tremendously from such a feature, much of which is already known to the compiler. The last 1% of cases are for academics to bicker over. I'm a programmer, dammit. :-)
Another feature that I really wanted to see would be a popup that tells you what O() order a function call would be, and have the compiler determine it based on analysis and corrective comments for difficult functions. Again, the halting problem applies here, but it would move a certain type of documentation into the face of a programmer, rather than obscurely in the middle of several nested functions.
:-)
The pre/post-condition validation at write time is an idea I've been toying with for the past two years. The problem is that (most) languages do not extend pre- and post-conditions into the language itself. Rather, you have to infer them based on types. This isn't strong enough. What you really need is a language that allows you to define not only the types, but the values or ranges that are legal as input and legal as output.
So, what I did was started from there and modified the grammar of C++ until it met all my requirements, then removed some things that would make such analysis impossible (like pointer arithmetic and anything else that contributes to weak typing), then added a few tweaks that I always wanted in my own language.
The result? An almost purely functional language, using C++ like syntax, with some unique features... for instance, one of my favorites was that scoping with braces { } works differently, such that you must declare all variables you take _into_ scope from the parent block, and you could poke locally declared variables _out_ of that scope into the parent block through another declaration. This follows exactly the same syntax as declaring a function, which made it trivial to rearrange blocks of code or inline things manually, etcetera. It also solves the problem of scope reduction for temporaries which are used only to call the constructor on a non-default constructor class.
Alas, I have no time to write the language, and considerably less to write an analysis tool like you describe, but it would have been neat to play with. A nearly perfectly functional language, as you know, parallelizes really well so I'd planned to put it on a cluster. Even bought the machines for it, then sold them when my interest waned.
I didn't get a close look at the article, so I can't say if it's a CRC16 or CRC32. Assuming a CRC32, the probability of a one-bit error making it through undetected is 1/2 ^ 32, or highly likely to be caught. However, multi-bit errors (from what I recall reading on CRC's recently) are _more_ likely to be caught. I can't locate a souce on that at the moment, but there are some interesting sources here that might prove fruitful.
Due to the nature of CRC, each successive bit radically changes the sum, so that single bit errors are easy to detect, and multi-bit errors are even easier, IIRC.
If they're going to take up storage real estate on a hard drive where you own the platters, but you can't use the data legally, they owe you compensation for the space they're stealing from you.
In short, charge them a monthly fee for having their data on your hard disk drive. Many companies do that as their primary business--selling external storage.
The sooner such practices as this bankrupt the businesses at fault, the sooner the practices go away.
There's a huge difference between a programmer and an analyst, as you describe it. Programmers create an eternal product, that is source code that solves a particular problem. Often, problems are recurrent and the same solution will work in an infinite number of cases. If you have access to the source code, it can be adapted to meet the changes in problem parameters. Some programmers can make it their life's work to maintain a single solution-giving set of source code, and get paid well to do so.
Analysis of a problem doesn't solve anything directly, so you work in a service-oriented field. It's information to be used or not used, but at the end of the day, you haven't solved the problem being analyzed. They might hire 20 analysts (wastefully) to provide insight or estimates, and they might all disagree, and they won't have solved the problem. However, after a programming team does their work, the problem is solved now and forever. Programmers are content/solution producers. Analysts are not.
I'm not judging either field. I'm simply stating that your analogy and your plea for "A Day's Pay For A Day's Work" is meaningful ONLY in a service oriented profession. Otherwise, you'd have musicians that could never get paid more than once for making a recording, and authors that would always get paid one time for a book, or programmers that could never sell the same software several times. Do you see the difference?
After hearing about how great a book this was for months after its initial release--from both good and bad programmers--I thought it would be worth looking into. So I picked up a copy and flipped through it, mainly hitting the patterns themselves.
What I found was there were a lot of abstract design ideas that now have names, which I suppose is a good thing. I was dissatisfied, however, with the quality of the content. A lot of the patterns were bad designs, and I didn't see any admonitions like 'you should never use this except in this very narrow case XYZ, where you don't have any control over the code to redesign it properly (3rd party libs) and it must exhibit ABC properties', but should have been. Just presenting designs with names is like loading a gun with multicolored bullets and handing it to a child.
After discussing the book with many co-workers, I noticed the trend that the programmers who tended to be more methodical and thorough in their up-front design, disliked the book, because it gave them no new ideas to work with, and introduced a number of useless designs on equal footing with the good ones. However, the programmers that were most scatterbrained and tended to play fast and loose with OOD and data flow, loved the book because it gave them a definitive reference for what to call the messes they create, without making judgements on their codepiles.
I'm not saying that it's a bad book, but I am saying it appeals to a crowd that needs that kind of book. Unfortunately, no book can teach Good Design. That author would be rich indeed.
I spent a couple of weeks tinkering with the idea a while back and wrote a server script in Perl that can run on any Win32 box (no compilers or anything necessary to be installed), and wrote a client script that plugs into MSVC++'s IDE. The client parses the build commands and contacts all servers through a UDP broadcast, then connects to each server, preprocesses a file at a time, transfers the processed C/C++ file and the compiler and its related binaries to the server, then sends the build commands to the server as well. All output is captured on the server and sent back to the client.
.cpp files together and only compiled that one file every time, so their build was a fixed (short) cost, and never hit any header twice. Dirty code that has module-local statics would choke on that technique, but for good code, it's prolly smarter than distributing it.
It worked pretty well, except I had a lot of problems getting fork to work right in Perl on my Win32 box without crashing, so I could get good parallelism. It even fell back to using the local machine in the event of a failure remotely at any point, so on a multiprocessor development machine and no servers to connect to, it would actually use all the processors to compile--something MSVC doesn't do normally.
The nice thing about the server script is it only has three functions: accept a file, send a requested file, and execute an arbitrary command. So it doesn't really care about what it's doing. At work, we're planning to use it to leech some cycles off the receptionist machines and managers' boxen (we all know they don't do anything all day but email anyway!).
The real limiting factor is that preprocessing is relatively slow due to seeks on the hard drive, where not all the headers fit in the disk cache at once. This is a bigger bottleneck than you'd believe.
For what it's worth, I've learned of another company that concatenated all their
Hardware page size is 4KB, as was noted elsewhere. The key element that I haven't seen mentioned is that Windows' virtual memory system has several ways to 'allocate' memory. There's reserving pages, and there's committing pages. In the case where you tell the OS you want memory, it reserves pages. That is to say, it does not actually take memory from the free physical memory, but instead creates a contiguous address space large enough for your request, but allocates no hardware RAM at those addresses.
When you commit a page, either through accessing a page (read or write) that is not allocated, it trips a hardware fault if the VM hasn't mapped a page to the address, which then searches for a free page, then links them together.
The end result is, even if Windows does try to create 64k worth of memory segment space for a process, unless it is actually reading or writing to a byte in each 4k chunk, its internal VM will not allocate physical memory for the whole 64k. Furthermore, there's no such advantage or realistic way for the operating system to align anything in memory physically, except in AGP ram. The VM system handles physical pages of memory exclusively, but does not manage AGP-allocated memory (IIRC). In other words, though the OS can align the address space to anything it likes, the OS layer cannot request any physical allocation mapping or alignment. So that comment about aligning memory for processes is quite unlikely.
Now, the XBox (which runs a variant of the Win2k kernel) has a bit more control over VM, but it also does not support demand paging, so it cannot swap to the hard disk and give you RAM+HD effective memory. Shame, that. But, as a result, you have an API that allows hardware level allocation control. Still, the OS doesn't take advantage of it, AFAIK. It's for developers.
It's important to ask yourself first, What does this piece of software do? Then, how far down the list of features that are important for it achieving that goal will you find Does it work with competing CMS's? Probably at the bottom, just below Can I use it as a text editor? :-)
As long as the CMS is stable and their formats are open, anyone can come along and write a bridge that lets them work together in a minimal sense. Asking for total interoperability is looking for total convergence of features, which is the long way of asking for only one system with slightly different interfaces.
My opinion, which only matters to me, is that each different system grew up because of a shortcoming of another, as applied to a particular situation. Making them interoperate may be impossible without losing those advantages.
Who signs the certificate? I don't want to pay Verisign $200/year just so I can send email. I certainly don't want more spam from Waitrose just because they paid Verisign $200 for a certificate.
Thawte does. For free. As far as I remember, it's an automated system that requires a good deal of info to generate a certificate, and has a higher privilege certificate for people who have been independently stamped, probably like the PGP/GPG web of trust.
The point isn't to make a whitelist, but to exclude anyone who doesn't use a certificate. It would probably then be an ISP service to give you a certificate with every account signup (or let you get your own, or use your previous one if you have one already), so it would be significantly less a barrier to entry for new users. I think it would raise the stakes significantly for spammers, especially since forging a certificate is a legal offense, since signed documents are admissible as evidence, IIRC.