You're missing the point. If you're eating your chicken salad sandwich, don't answer the phone. Let caller ID pick it up, finish your sandwich, and then if you're remotely concerned that you might have missed a call that you cared about, you can check caller ID. If it's some asshat calling just because he has your number on hist caller ID, and it's not a number that you recognize, forget about it and move on with your life. One of the 5 other people in the house will see that number eventually and if the call is important to them they'll call that guy back themselves.
Amen. This is a disturbing trend...it seems like there are fewer and fewer titles being made available for Mac since OS X came out. Team 17 made a few Worms titles for Mac back in the day, and now you can't find them anywhere.
Still, it seems odd that they would release RealMYST on the Mac and not Uru. I imagine the Uru engine is derived at least somewhat from the RealMYST engine...so why not?
I bet we'll see a Mac release about 6 months after the debut, which may be a blessing in disguise, given the bugginess of online games (especially early on).
What if they just hashed the ID3 values? Then it doesn't matter how the MP3 was encoded, since there is a reasonably good chance that most MP3s of the same song will contain the same ID3 tag information, especially given that a lot of rippers use CDDB and FreeDB. You could also extend the likelihood of a match by trimming extra whitespace and making all text lowercase before hashing.
If I were the RIAA, that's how I would do it. It's like a filename search, but less prone to false positives like "Usher.mp3". And lets face it, if your ID3 tags match then it's probably the MP3 they're looking for, and it probably shouldn't be publicly accessible from your PC.
1) The difference between any two point releases of Mac OS X is like going from Windows 95 to Windows XP. So for a loyal Windows user to get the same benefit, he or she would have to shell out $139 for Windows 98 Upgrade, $139 for Windows 2000 Upgrade, and $139 for XP Upgrade. That's over $400 for what? Bug fixes, new drivers, and slight UI changes. No new apps, and certainly nothing innovative. No, for $129 I get a FULL version of the next Mac OS, and it is well worth the purchase. And while I'm waiting, I get individual application updates and security patches for free through the System Update applet.
2) Mac has Office, Internet Explorer, and a pretty darn intuitive samba interface. I've never had a problem interfacing with Windows PCs. Granted, a lot of enterprise applications, such as Metasolv TBS and ADC Express/SingleView don't come in Mac flavors, but as Web-based UIs become more prevalent (and they are) this will cease to be an issue.
3) Half of our company is running on PIII 500s because we never budget to replace PCs, only to buy new ones. I don't think we're alone in that. What's more, nobody complains, because it's plenty of horsepower to play with spreadsheets and send E-mail with. You can argue that Macs are behind Intel as far as power goes, but you can't argue that the speed at which Macs are available today (G3s are very affordable, btw) is not sufficient for most business needs.
I'd also like to throw in that as a Unix developer/admin that has to also use Outlook and Word, a Mac would be ideal. Rather than have two PCs, one for E-mail and one for work, I can use one, making use of Office for Mac for the former and the OpenBSD core for the latter.
Yes, we're on an Intranet, but we have salespeople in 9 states that are connected via VPN. Deploying a Windows Forms application to 250 remote laptops is not something we wanted to mess with. Besides, ASP.NET and Web Forms are one of the things I like about.NET...it's the backend stuff (ADO, BizTalk, MTS) that kills you.
The I/O functionality consists nearly entirely of static methods that, frankly, don't do a lot for you. You can get a list of filenames in a directory, but I haven't found anything that will parse the filename into path segments and reformat it for various platforms. Java does this wonderfully, and the functionality betwee java.io and java.net allows you to do really neat things with paths OR URLs (you don't have to know or care which, Java does that for you).
But what I miss most is that in Java, when you call read( byte[] a ) it will read a.length bytes and advance the file pointer so you can perform the same call in a loop until the returned value is less than a.length. In.NET read( byte[] a, int b, int c ) only reads c - b bytes and does *not* advance the pointer. Interestingly, b and c are ints, whereas the file length can be long, so conceivably you could be unable to read the end of a very long file (that is, if there is a distinction between int and long in.NET). The only way to read in a file in a loop is byte-by-byte (read( ) advances the pointer just fine), which is *very* inefficient. I ran into that while trying to copy an HttpPostedFile into a blob field on a data object. Pain in the ass.
With respect to I/O, it looks like.NET gives you little more than what you get with a standard C++. I guess I'm just spoiled by Java, which has an extremely robust I/O package.
- The way codebehind is implemented, and the ASP.NET page lifecycle - Custom controls - Properties and indexers - Collection and foreach - Events and delegates - app.config and web.config - XCopy deployment - Newsgroup support
What I don't like about.NET:
- Buggy implementation - Crappy file I/O package - DLL Versioning (Pain in the ass. Just deprecate!) - Crappy API documentation - A lot of default behaviors, little of which is intuitive, predictable, or documented - The inability to use classes effectively for things they weren't designed to work for, even though they would be perfect for the job. This is largely due to shortsighted design and access constraints (private methods, un-settable properties, etc)
In other words, I love the CLR design and syntactical shortcuts and hate the class libraries and implementation. The feature set is very wide but not very deep. It's painfully obvious where they've set their focus (ASP.NET, ADO.NET) and where they haven't (file I/O, date/time manipulation, string formatting, etc). You develop like lightening until you reach a point where you want to refine it a bit and make it do something very specific, then you spend weeks trying to figure out what it's doing, why it's doing it that way, and how to work around the default behavior.
It's a good product for small projects, but if you're doing enterprise applications, you're better off implementing a lot of this stuff yourself. A good example are typed DataSets...they manage rowstate and updates and such, which saves a lot of time in the short term, but a lot of the time you want much finer control and a looser coupling between business objects and the data schema. Unfortunately, you can't touch the rowstate directly, which leads to some pretty interesting (and ugly) solutions.
For what it's worth, SuSE issued a press release immediately following the announcement of the lawsuit that distanced them from SCO. Since SuSE is pretty much the backbone of the group, I don't expect the UnitedLinux thing to pan out (unless, of course, it turns out to be nothing more than a rebranding of SuSE Linux).
UnitedLinux was a business venture, nothing more. Before you get all self-righteous, consider that contributions that SuSE has made to Linux: several XF86 drivers, USB support, ALSA, and many more I'm sure. They may have a proprietary installation/package management system, but cut the guys some slack. We all have to eat, and the core functionality is still free.
The thing I like about Java is that it enforces best practices. Looking at the capabilities of the language it seems like the inventor sat down and said, "okay, here's all of the things I need to do. Now what are is the minimum number of keywords and constructs I can implement and still be able to do all of them." Good examples of this would be single inheritance with interfaces; lack of explicit virtual functions (all functions are virtual); the well-defined and supported Bean model of Get and Set methods (as opposed to readonly member variables or properties); and the I/O and collections classes. I don't care what the trolls may say, from Java 1.2 there are very obvious conventions that are easy to follow and understand, and looking at the API you can usually tell exactly how the author intended the class to be used.
I'm doing C# now (not by choice) and one of the major gripes I have is that C# supports so much in the way of syntax that there is no way to establish and uphold best practices. And although the API is some 8000 classes, basic stuff like I/O and collections were severely neglected. So now I have tons of syntactical variations I can use, but no idea how to use them properly. Meanwhile I'm left writing custom collections classes for just about anything that doesn't fit nicely in a Hashtable or ArrayList. And I still haven't figured out what crack the I/O team was smoking when they designed the file access classes.
But all languages have their downsides; I do happen to like the concept of object properties even if the C# implementation stinks, and the.NET development environments have Java whooped bigtime. But IMO the breadth of features in.NET is no match for the depth of features in a more mature language like Java or C++. And my only gripe against C++ is that it doesn't manage memory or object references for you, which, depending on your performance needs, is either a blessing or a curse.
But what is the cost of familiarizing the new programmers with existing systems? A particular fix may take the programmer who designed the system 5 minutes to implement and 10 minutes to test, whereas a programmer off the street (looking for work, so probably in the bottom 6.1% in terms of talent) may take weeks to even find where to implement the patch. That's *if* they manage to discover the appropriate place to implement it--they can do much more damage with a quick fix in the wrong place.
It's much cheaper to treat your employees right and earn their loyalty. Do that and they'll gladly pitch in during tough times to pull off a deadline. Let them know that the effort is greatly appreciated and beyond what is expected of them, and give them some comp time when you get a chance. The worst thing you can do is demand overtime, because then your talented coders quit and go elsewhere and the less talented ones put out half-assed, buggy code, thus extending the testing and maintenance cycle.
iCal for MacOS X allows multiple calendars, each overlayed in a different translucent color. You can activate or deactivate the display of each independently. It has exactly the same flexibility as the Outlook calendar when it comes to recurring events as well. I thought that was pretty inventive...comes in handy when juggling work, school, and my personal life (red, blue, and green, respectively).
Whether or not that helps you, I dunno, but applications like that certainly do exist.
How about adjusting the price so that with tax it comes out to an even amount? For instance, a $0.93 cent snack with 7.5% tax = $1.00 (with rounding). That way they wouldn't have to print both (and worry about them going out of synch) but you'd still solve the change problem.
I'm guessing the reason this isn't done is that the market-supported price (especially on low-cost items) is not an even denomination. If you rounded up to the nearest dollar you'd screw up your supply/demand curve some. They probably price things at the exact price that the market will bear and to hell with tax.
The ideal solution, of course, is to use some kind of card to store data, maybe with a magnetic strip, that you could give to the person at the register. They could then read the data off of the card, probably an account code of some sort, and communicate with the bank to perform the transaction at the point of sale. Of course, you'd need a signature or password or something to prevent fraud, but at least you wouldn't have to worry about change;)
Exactly. I used to architect and develop entire frameworks for internal development. Now I write templates for code generation. It's a little distressing at first...it looks like your job's being replaced by a computer...but what's really happening is that all the copy/paste/replace you used to do is being automated. There is still a need for talented designers and architects to develop metadata, design code templates, and write code generation utilities. Even then there is still room for one or two developers to come behind and tweak objects for specific validation rules and work on integration.
The software industry isn't going away, it's just getting smarter. More is being done with less, which means more higher paying jobs for highly skilled positions and fewer for copy/paste codemonkeys.
1. Offer (optional) CD creation services at various levels: CD with generic label, CD with custom label, and CD with custom label and insert (album art and lyrics)
2. Publish web services for publishing and consuming orders. That way you could set up partner services for promotions, and bands could automate CD printing and delivery if they opt not to pay for the CD creation services.
With those two things this would be a very powerful service.
Depends on your definition of "survive". As long as somebody is sufficiently motivated by philosophy, politics, prestige, or just plain cheapness open projects will continue to evolve. Some people code for *fun*...at least it's a hobby you don't have to sink a lot of money into.
Now, if by "survival" you mean market domination, then as long as people are willing to put up with bugs and security flaws in order to have the latest incarnation of every feature possible open source will lag behind in adoption.
There are a million reasons to write code and history has shown that money is probably not the best one in terms of robustness, security, and longevity.
The IR port and remote are sold separately. The IR port plugs into one of the game controller slots and has a port on the other side to allow a game controller to be plugged in as well.
I would have just modded you down, but I'm tired of this kind of ignorance. There are multiple forms of trusted computing, some innocent, others questionable. Since 2000 IBM has offered an (optional) ESS (Electronic Security Subsystem) in their Thinkpads and Netvistas. All it is is an embedded smart card with a keypair and some crypto functions. It's a passive device...if you feal like encrypting something then you have a convenient mechanism with which to do it. Before that, in 1998, SISTex offered the Assure EC networking device that merely served as a secure interface between an IBM compatible workstation software, local resources, and the network.
TCPA specifies a similar device (the Trusted Platform Module), only it also has a few registers used to store and report security integrity metrics as well. Again, a totally passive device. From what I gather, the idea is that the BIOS and/or OS will use these registers to store the version of software, virus checkers, etc. Another system can query these registers to see if you have what they're looking for in the way of security (I wouldn't want to accept E-mail from a server that, say, wasn't patched for Code Red).
So there's a key stored in your TPM. Worried about privacy? Don't be. That key is never used except to sign other keys, alias IDs, that you use temporarily to conduct transactions. Like getting an alias for your credit card number when buying something online.
All of these are passive devices that you, the operating system, or third party apps may or may not use. None of these technologies have functions that allow the conditional execution of code based on security metrics. That is an abuse that must be built into the OS, which can be done today in software.
Then there's Palladium, which is *not* TCPA. It's not even based on the TCPA. It's similar, but it consists of both hardware and software components (Windows) and is potentially much more sinister. Palladium's only member is Microsoft, and I don't really trust that. But I don't have to, because there are now ubiquitous, open standards (TCPA) that will likely take favor.
We need trusted computing. It's coming. You can help yourselves by at least being informed:
Not as much as you would think. They do offer an MS schema that has a lot of built-in datatypes for creating your own XML schema, but that's expected. That's part of why XML schema is so great--you can define and reuse element types. Granted, if you choose to use those extensions then you're marrying yourself to that schema, and therefore to Microsoft, but that's up to you. You can still do alright using the standard XML schema types put out by the W3C.
(Now I can't speak for the IDE...the tools MS produces probably make use of the extensions whether you like it or not)
Anyway, down with Microsoft and all that, but I haven't seen them play dirty with.NET yet (at least as far as XML goes).
It's not XML's fault that Microsoft isn't implementing it.
Are you smoking crack? I hate Microsoft as much as the next guy, but have you seen.NET? Holy cow. Everything having to do with data sets has been XML-ized, from query results to transactions to SOAP...you can't swing a dead cat without writing a schema first. Look at SQL Server 2000...everything can be done in XML. And then ASP.NET is XML-based (using the convention), and lets not forget the.NET app web.config file, which is XML.
Granted, MS hasn't backported everything to XML (think we'll ever see an XML registry?) but everything going forward has XML tattooed all over it. I happen to love XML, but if anything Microsoft tends toward the zealous side.
The article says that devices will have to install a module (less than a millimeter thick, and costing about $0.25) in order to make use of the pad. And as long as I get a day of use out of my device, I don't care if it takes all night to charge.
This is an awesome innovation and just the excuse I've been looking for to upgrade my cellphone:)
Try the Via C3 ITX CPU/motherboard combos. You can build a machine that runs without a fan and has something like 11"x10"x2" footprint. There's a few sites out there that build complete systems with slimline CD-ROMS (or DVDs) for around $400.
There is. It's called XML Path, or XPath for short. The following string, for example, would return a list of text nodes for all of the children of a specific parent:
rootElement/parent[@name='Jane']/child/text()
I can also return the parents with children named "John":
rootElement/parent[child[@name='john']]
Or the name of the parents with children named "John":
rootElement/parent[child[@name='john']]/@name
And you get the idea. You can do a lot more with it as well, including number and string comparisons, sorting, and a number of other function doo-dads. It's really sweet. If you use Java give Apache Xalan a shot.
But it does have one drawback: you have to use DOM to use it. Theoretically, it should be possible to write a SAX version, but every time you queried the document you'd have to read through the whole file. An ideal solution would be to create an index using SAX and then optimize the XPath expression evaluator to use that index.
But I digress. The point was to say that the XML toolkit supports a variety of solutions, from DOM to SAX to XPath to XSLT that do things quickly and easily (depending on the API you use). If he doesn't want to use DOM (and in this case he shouldn't) he needs to use some kind of Perl SAX API...the regex stuff he's doing is a little over the top in my opinion.
Slashdot Mirror
You're missing the point. If you're eating your chicken salad sandwich, don't answer the phone. Let caller ID pick it up, finish your sandwich, and then if you're remotely concerned that you might have missed a call that you cared about, you can check caller ID. If it's some asshat calling just because he has your number on hist caller ID, and it's not a number that you recognize, forget about it and move on with your life. One of the 5 other people in the house will see that number eventually and if the call is important to them they'll call that guy back themselves.
Amen. This is a disturbing trend...it seems like there are fewer and fewer titles being made available for Mac since OS X came out. Team 17 made a few Worms titles for Mac back in the day, and now you can't find them anywhere.
Still, it seems odd that they would release RealMYST on the Mac and not Uru. I imagine the Uru engine is derived at least somewhat from the RealMYST engine...so why not?
I bet we'll see a Mac release about 6 months after the debut, which may be a blessing in disguise, given the bugginess of online games (especially early on).
What if they just hashed the ID3 values? Then it doesn't matter how the MP3 was encoded, since there is a reasonably good chance that most MP3s of the same song will contain the same ID3 tag information, especially given that a lot of rippers use CDDB and FreeDB. You could also extend the likelihood of a match by trimming extra whitespace and making all text lowercase before hashing.
If I were the RIAA, that's how I would do it. It's like a filename search, but less prone to false positives like "Usher.mp3". And lets face it, if your ID3 tags match then it's probably the MP3 they're looking for, and it probably shouldn't be publicly accessible from your PC.
1) The difference between any two point releases of Mac OS X is like going from Windows 95 to Windows XP. So for a loyal Windows user to get the same benefit, he or she would have to shell out $139 for Windows 98 Upgrade, $139 for Windows 2000 Upgrade, and $139 for XP Upgrade. That's over $400 for what? Bug fixes, new drivers, and slight UI changes. No new apps, and certainly nothing innovative. No, for $129 I get a FULL version of the next Mac OS, and it is well worth the purchase. And while I'm waiting, I get individual application updates and security patches for free through the System Update applet.
2) Mac has Office, Internet Explorer, and a pretty darn intuitive samba interface. I've never had a problem interfacing with Windows PCs. Granted, a lot of enterprise applications, such as Metasolv TBS and ADC Express/SingleView don't come in Mac flavors, but as Web-based UIs become more prevalent (and they are) this will cease to be an issue.
3) Half of our company is running on PIII 500s because we never budget to replace PCs, only to buy new ones. I don't think we're alone in that. What's more, nobody complains, because it's plenty of horsepower to play with spreadsheets and send E-mail with. You can argue that Macs are behind Intel as far as power goes, but you can't argue that the speed at which Macs are available today (G3s are very affordable, btw) is not sufficient for most business needs.
I'd also like to throw in that as a Unix developer/admin that has to also use Outlook and Word, a Mac would be ideal. Rather than have two PCs, one for E-mail and one for work, I can use one, making use of Office for Mac for the former and the OpenBSD core for the latter.
Side note to this: a half-windsor may take a little longer to tie, but it's a hell of a lot more comortable then a simple knot (and looks better too).
Yes, we're on an Intranet, but we have salespeople in 9 states that are connected via VPN. Deploying a Windows Forms application to 250 remote laptops is not something we wanted to mess with. Besides, ASP.NET and Web Forms are one of the things I like about .NET...it's the backend stuff (ADO, BizTalk, MTS) that kills you.
The I/O functionality consists nearly entirely of static methods that, frankly, don't do a lot for you. You can get a list of filenames in a directory, but I haven't found anything that will parse the filename into path segments and reformat it for various platforms. Java does this wonderfully, and the functionality betwee java.io and java.net allows you to do really neat things with paths OR URLs (you don't have to know or care which, Java does that for you).
.NET read( byte[] a, int b, int c ) only reads c - b bytes and does *not* advance the pointer. Interestingly, b and c are ints, whereas the file length can be long, so conceivably you could be unable to read the end of a very long file (that is, if there is a distinction between int and long in .NET). The only way to read in a file in a loop is byte-by-byte (read( ) advances the pointer just fine), which is *very* inefficient. I ran into that while trying to copy an HttpPostedFile into a blob field on a data object. Pain in the ass.
.NET gives you little more than what you get with a standard C++. I guess I'm just spoiled by Java, which has an extremely robust I/O package.
But what I miss most is that in Java, when you call read( byte[] a ) it will read a.length bytes and advance the file pointer so you can perform the same call in a loop until the returned value is less than a.length. In
With respect to I/O, it looks like
What I like about .NET:
.NET:
- The way codebehind is implemented, and the ASP.NET page lifecycle
- Custom controls
- Properties and indexers
- Collection and foreach
- Events and delegates
- app.config and web.config
- XCopy deployment
- Newsgroup support
What I don't like about
- Buggy implementation
- Crappy file I/O package
- DLL Versioning (Pain in the ass. Just deprecate!)
- Crappy API documentation
- A lot of default behaviors, little of which is intuitive, predictable, or documented
- The inability to use classes effectively for things they weren't designed to work for, even though they would be perfect for the job. This is largely due to shortsighted design and access constraints (private methods, un-settable properties, etc)
In other words, I love the CLR design and syntactical shortcuts and hate the class libraries and implementation. The feature set is very wide but not very deep. It's painfully obvious where they've set their focus (ASP.NET, ADO.NET) and where they haven't (file I/O, date/time manipulation, string formatting, etc). You develop like lightening until you reach a point where you want to refine it a bit and make it do something very specific, then you spend weeks trying to figure out what it's doing, why it's doing it that way, and how to work around the default behavior.
It's a good product for small projects, but if you're doing enterprise applications, you're better off implementing a lot of this stuff yourself. A good example are typed DataSets...they manage rowstate and updates and such, which saves a lot of time in the short term, but a lot of the time you want much finer control and a looser coupling between business objects and the data schema. Unfortunately, you can't touch the rowstate directly, which leads to some pretty interesting (and ugly) solutions.
For what it's worth, SuSE issued a press release immediately following the announcement of the lawsuit that distanced them from SCO. Since SuSE is pretty much the backbone of the group, I don't expect the UnitedLinux thing to pan out (unless, of course, it turns out to be nothing more than a rebranding of SuSE Linux).
UnitedLinux was a business venture, nothing more. Before you get all self-righteous, consider that contributions that SuSE has made to Linux: several XF86 drivers, USB support, ALSA, and many more I'm sure. They may have a proprietary installation/package management system, but cut the guys some slack. We all have to eat, and the core functionality is still free.
The thing I like about Java is that it enforces best practices. Looking at the capabilities of the language it seems like the inventor sat down and said, "okay, here's all of the things I need to do. Now what are is the minimum number of keywords and constructs I can implement and still be able to do all of them." Good examples of this would be single inheritance with interfaces; lack of explicit virtual functions (all functions are virtual); the well-defined and supported Bean model of Get and Set methods (as opposed to readonly member variables or properties); and the I/O and collections classes. I don't care what the trolls may say, from Java 1.2 there are very obvious conventions that are easy to follow and understand, and looking at the API you can usually tell exactly how the author intended the class to be used.
.NET development environments have Java whooped bigtime. But IMO the breadth of features in .NET is no match for the depth of features in a more mature language like Java or C++. And my only gripe against C++ is that it doesn't manage memory or object references for you, which, depending on your performance needs, is either a blessing or a curse.
I'm doing C# now (not by choice) and one of the major gripes I have is that C# supports so much in the way of syntax that there is no way to establish and uphold best practices. And although the API is some 8000 classes, basic stuff like I/O and collections were severely neglected. So now I have tons of syntactical variations I can use, but no idea how to use them properly. Meanwhile I'm left writing custom collections classes for just about anything that doesn't fit nicely in a Hashtable or ArrayList. And I still haven't figured out what crack the I/O team was smoking when they designed the file access classes.
But all languages have their downsides; I do happen to like the concept of object properties even if the C# implementation stinks, and the
But what is the cost of familiarizing the new programmers with existing systems? A particular fix may take the programmer who designed the system 5 minutes to implement and 10 minutes to test, whereas a programmer off the street (looking for work, so probably in the bottom 6.1% in terms of talent) may take weeks to even find where to implement the patch. That's *if* they manage to discover the appropriate place to implement it--they can do much more damage with a quick fix in the wrong place.
It's much cheaper to treat your employees right and earn their loyalty. Do that and they'll gladly pitch in during tough times to pull off a deadline. Let them know that the effort is greatly appreciated and beyond what is expected of them, and give them some comp time when you get a chance. The worst thing you can do is demand overtime, because then your talented coders quit and go elsewhere and the less talented ones put out half-assed, buggy code, thus extending the testing and maintenance cycle.
iCal for MacOS X allows multiple calendars, each overlayed in a different translucent color. You can activate or deactivate the display of each independently. It has exactly the same flexibility as the Outlook calendar when it comes to recurring events as well. I thought that was pretty inventive...comes in handy when juggling work, school, and my personal life (red, blue, and green, respectively).
Whether or not that helps you, I dunno, but applications like that certainly do exist.
How about adjusting the price so that with tax it comes out to an even amount? For instance, a $0.93 cent snack with 7.5% tax = $1.00 (with rounding). That way they wouldn't have to print both (and worry about them going out of synch) but you'd still solve the change problem.
;)
I'm guessing the reason this isn't done is that the market-supported price (especially on low-cost items) is not an even denomination. If you rounded up to the nearest dollar you'd screw up your supply/demand curve some. They probably price things at the exact price that the market will bear and to hell with tax.
The ideal solution, of course, is to use some kind of card to store data, maybe with a magnetic strip, that you could give to the person at the register. They could then read the data off of the card, probably an account code of some sort, and communicate with the bank to perform the transaction at the point of sale. Of course, you'd need a signature or password or something to prevent fraud, but at least you wouldn't have to worry about change
Exactly. I used to architect and develop entire frameworks for internal development. Now I write templates for code generation. It's a little distressing at first...it looks like your job's being replaced by a computer...but what's really happening is that all the copy/paste/replace you used to do is being automated. There is still a need for talented designers and architects to develop metadata, design code templates, and write code generation utilities. Even then there is still room for one or two developers to come behind and tweak objects for specific validation rules and work on integration.
The software industry isn't going away, it's just getting smarter. More is being done with less, which means more higher paying jobs for highly skilled positions and fewer for copy/paste codemonkeys.
What they need to do is:
1. Offer (optional) CD creation services at various levels: CD with generic label, CD with custom label, and CD with custom label and insert (album art and lyrics)
2. Publish web services for publishing and consuming orders. That way you could set up partner services for promotions, and bands could automate CD printing and delivery if they opt not to pay for the CD creation services.
With those two things this would be a very powerful service.
Depends on your definition of "survive". As long as somebody is sufficiently motivated by philosophy, politics, prestige, or just plain cheapness open projects will continue to evolve. Some people code for *fun*...at least it's a hobby you don't have to sink a lot of money into.
Now, if by "survival" you mean market domination, then as long as people are willing to put up with bugs and security flaws in order to have the latest incarnation of every feature possible open source will lag behind in adoption.
There are a million reasons to write code and history has shown that money is probably not the best one in terms of robustness, security, and longevity.
The IR port and remote are sold separately. The IR port plugs into one of the game controller slots and has a port on the other side to allow a game controller to be plugged in as well.
They sell for $40 I think.
I would have just modded you down, but I'm tired of this kind of ignorance. There are multiple forms of trusted computing, some innocent, others questionable. Since 2000 IBM has offered an (optional) ESS (Electronic Security Subsystem) in their Thinkpads and Netvistas. All it is is an embedded smart card with a keypair and some crypto functions. It's a passive device...if you feal like encrypting something then you have a convenient mechanism with which to do it. Before that, in 1998, SISTex offered the Assure EC networking device that merely served as a secure interface between an IBM compatible workstation software, local resources, and the network.
TCPA specifies a similar device (the Trusted Platform Module), only it also has a few registers used to store and report security integrity metrics as well. Again, a totally passive device. From what I gather, the idea is that the BIOS and/or OS will use these registers to store the version of software, virus checkers, etc. Another system can query these registers to see if you have what they're looking for in the way of security (I wouldn't want to accept E-mail from a server that, say, wasn't patched for Code Red).
So there's a key stored in your TPM. Worried about privacy? Don't be. That key is never used except to sign other keys, alias IDs, that you use temporarily to conduct transactions. Like getting an alias for your credit card number when buying something online.
All of these are passive devices that you, the operating system, or third party apps may or may not use. None of these technologies have functions that allow the conditional execution of code based on security metrics. That is an abuse that must be built into the OS, which can be done today in software.
Then there's Palladium, which is *not* TCPA. It's not even based on the TCPA. It's similar, but it consists of both hardware and software components (Windows) and is potentially much more sinister. Palladium's only member is Microsoft, and I don't really trust that. But I don't have to, because there are now ubiquitous, open standards (TCPA) that will likely take favor.
We need trusted computing. It's coming. You can help yourselves by at least being informed:
"The Need for TCPA" (David Safford, IBM)
"Clarifying Misinformation on the TCPA" (David Safford, IBM)
Not as much as you would think. They do offer an MS schema that has a lot of built-in datatypes for creating your own XML schema, but that's expected. That's part of why XML schema is so great--you can define and reuse element types. Granted, if you choose to use those extensions then you're marrying yourself to that schema, and therefore to Microsoft, but that's up to you. You can still do alright using the standard XML schema types put out by the W3C.
.NET yet (at least as far as XML goes).
(Now I can't speak for the IDE...the tools MS produces probably make use of the extensions whether you like it or not)
Anyway, down with Microsoft and all that, but I haven't seen them play dirty with
Yet another reason NOT to be a proctologist...
Are you smoking crack? I hate Microsoft as much as the next guy, but have you seen
Granted, MS hasn't backported everything to XML (think we'll ever see an XML registry?) but everything going forward has XML tattooed all over it. I happen to love XML, but if anything Microsoft tends toward the zealous side.
The article says that devices will have to install a module (less than a millimeter thick, and costing about $0.25) in order to make use of the pad. And as long as I get a day of use out of my device, I don't care if it takes all night to charge.
:)
This is an awesome innovation and just the excuse I've been looking for to upgrade my cellphone
Try the Via C3 ITX CPU/motherboard combos. You can build a machine that runs without a fan and has something like 11"x10"x2" footprint. There's a few sites out there that build complete systems with slimline CD-ROMS (or DVDs) for around $400.
Here's a link:
http://www.mini-itx.com/store/
What a relief!
There is. It's called XML Path, or XPath for short. The following string, for example, would return a list of text nodes for all of the children of a specific parent:
rootElement/parent[@name='Jane']/child/text()
I can also return the parents with children named "John":
rootElement/parent[child[@name='john']]
Or the name of the parents with children named "John":
rootElement/parent[child[@name='john']]/@name
And you get the idea. You can do a lot more with it as well, including number and string comparisons, sorting, and a number of other function doo-dads. It's really sweet. If you use Java give Apache Xalan a shot.
But it does have one drawback: you have to use DOM to use it. Theoretically, it should be possible to write a SAX version, but every time you queried the document you'd have to read through the whole file. An ideal solution would be to create an index using SAX and then optimize the XPath expression evaluator to use that index.
But I digress. The point was to say that the XML toolkit supports a variety of solutions, from DOM to SAX to XPath to XSLT that do things quickly and easily (depending on the API you use). If he doesn't want to use DOM (and in this case he shouldn't) he needs to use some kind of Perl SAX API...the regex stuff he's doing is a little over the top in my opinion.