When I was in Sydney last year, I ran into some folks at an XML conference that were pushing the Royal Melbourne Institute of Technology's then-new all-online certificate and degree programs. The program seems pretty solid, and the University is a hotbed of XML work. They have since been marketing to me pretty hard, and both my conversations with them and the materials portray it as a no-bullshit all-web-based program for BS, MS, and PhD in technical fields. Check it out the online program here.
While it seems all well and good, can anyone who has actually attended a program there comment on it? RMIT seems more serious than the current wave of schools using the shovelware method of developing online course offerings. Is it as good as it appears?
Memory stick, phooey! And is it just me, or does Sony's prorietary "ATRAC3" music format sound suspiciously like "8-track v.3"?
While I welcome several aspects of this (Sony teaming up with Palm instead of WinCE, motivation to boost Palm hardware cpu power, general competition), I'm a little disappointed that it'll push Palm further down a proprietary road. I'm simply not interested in buying into any technology that has hand-slapping of perceived-errant consumers built into it. No Sony memory sticks for me. Maybe my next PDA will be a Visor. But then again, the idea of playing 8-tracks with my Palm is strangely appealing...:)
[I put a bit of thought into this, so I've crossposted my comment from Forbes.]
Like many professionals reading this (I think I can safely speak for many at this level), I'm disappointed both by JP's behavior and methods of operation, and by the community response. While it's pretty clear that JP is far less experienced and far more vindictive than he represents, you have to give the guy some credit for standing up to a wall of immature criticism. For example, the lack of intelligent questions in yesterday's Slashdot interview was very disappointing; I'd have liked to see something along the lines of "What do you see as the next few steps in the evolution of remote NT cracking" or "What would you recommend as a baseline security configuration for deployment of a small XYZ-based ecommerce site?"
Of course, I'm the only one to blame for not posting these questions. Why did I not post them? Because previous experience tells me that the responses would be ill-researched and of little use. JP does not have anything new or interesting to offer in this arena. Perhaps that's a little hypocritical of me -- criticising the community for lack of reasonable questions when I failed to contribute. But then again, it's clear that the feeling was common. What a waste of community brain-cycles.
For the sake of argument, how can JP become a respected individual in the security arena? It's clear he's got a talent -- just not in the mechanics of system or network security. He's an excellent consciousness-raiser, even if his methods need some cleanup. (The comparison to Howard Stern was excellent.) Perhaps he would be a good addition to a security consultancy that has a lot of introverted systems gurus with good leadership and financial backing, but needs someone with basic knowledge and a talent for verbal evangelism. With the proper organizational guidance and support from a technical research team that actually knows its stuff, he could actually do some good in this world. As it stands, however, he's overextended the boundaries of his knowledge and talent, and brings the whole security community down by inciting the online and legal equivalent of schoolyard fistfights.
grey@enigma.mips4.com writes: I'm not sure what companies have to go throgh to get authorization to do electronic transfers by account number, but with abuses it could undoubtedly be revoked. One would hope it's fairly difficult to get and has high penalties for abuse...
Here's the criteria: A vendor goes to their bank, gives their bank your account number and bank routing number. If questioned, the vendor may have to sign a statement that they have your authorization on file, but nothing more. In common practice, there is no actual verification of your authorization -- the originating bank takes the initiator's statement as your authorization.
As for penalties, it appears that it's on the same level as writing a bad check. If the vendor makes enough unauthorized transactions, someone at that bank might slap their wrist -- and send them along to the next bank. Pathetic and sad, indeed. I used to work (long ago) as a banking MIS drone, yet the more I deal with that industry as a consumer, the more I'm consistently horrified by the endemic negligence and resistance to new knowledge.
Ater reading a gob o' comments, it seems like most semi-aware folks are disgusted by the blithely ignorant ways of the US patent office. Few, however, have ideas about what to do. Lobbying is good. Opening the eyes of the mainstream media is good (the ABC News (I think) coverage on gene patents the other day was fantastic). But it's not enough.
But how about more focused public discussion? Tossing these up on/. is somewhat constructive, but it seems to me that that's a step short of a public discussion forum dedicated to discovery of prior art. Instead of lamenting about how bad the patent process is on/., howzabout a place where every article is a ridiculous patent, and the typical reply is "check out XXXX and YYY which both did this years before LudicrousPatentFiler Inc did." Moderation categories could include "prior art," "common knowledge," "other patent infringment," "nonoperative," or -- god forbid -- "valid."
The mere existence of such a community-led patent debunker might make the average company a bit more careful about throwing several thousand dollars at a patent that gets invalidated in an hour or two.
Where did that/source go, anyway? Think I could run such a thing on a 384k dsl line?
Since you brought up the spectre of financial institutions' ideas on security, the following recent personal experience should provide some insight into the current state of thinking among some in the US:
I applied for life insurance with a major reputable company, and was accepted. Their typical m.o. is to set up automatic withdrawal, but I declined and wrote them a check for a full year premium (several hundred dollars). About a week later, I received a confirmation from them that they had automatically withdrawn the full amount using the account number taken off my check AND cashed my check. I immediately called to ask why they had done this, and they were gracious enough to immediately reverse the automatic withdrawal by making another unauthorized transaction to my account -- this time a deposit.
I'm a little irritated at the insurance company, but I was infuriated that my bank allowed these multiple unauthorized transactions. So I inquired further. It turns out that my bank (Washington Mutual, based in Seattle) does not know the difference between identification and authorization! Their position is that I gave authorization to the insurance company by giving them my account number, which was printed on the bottom of my check. I informed the bank that (a) in fact I had not given the number, but that it was taken from my check, and (b) that the number is identification, not authorization.
Neither of these facts fazed them one bit. In numerous calls and personal visits (I happen to be working near their headquarters), I could not find a single individual who understood that there was a difference between identification and authorization. What does this mean? IMHO, it means that there is no interest in even password-level security. Sure, they understand that when a customer looks at their account summary online they need to have a name and password, but when Joe Random fishes my check stubs out of the shredder and learns my account identity, the bank will duly process every one of his automatic withdrawal transactions without authorization. The kicker is that WAMU informed me that there is no way to refuse this type of transaction -- if I have an account with them, I *must* accept this idiotic risk. Needless to say, I'm investigating whether my credit union has a similarly brain-dead policy. (I'm afraid, however, that this may be the result of nationwide transaction policy -- perhaps even mandated by Federal Reserve rules.)
With respect to the main topic, this has some frightening implications. My bank not only allows informational access, but transactional access, without real authorization. Ok, so someone can steal money from me and my bank officially considers me to be at fault. This sort of SNAFU won't necessarily do me in. But what happens if online access to medical information takes the same route? What if I can not only inquire as to my own information, but I have transactional access as well (such as requesting medication refills, changing my ship-to-address, reporting my progress in treatment, etc etc)? This could kill me -- literally. I applaud the effort to provide strong security, and if it's offered, I'll opt into it. But right now I'm concerned about just basic authentication.
The question that immediately comes to mind is how to organize the code. CPAN is PERL-specific, and other repositories tend to be similar in terms of supporting a single language.
On the other hand, the purpose of the proposed repository is to support the distribution, improvement, and archiving of GPL code. IHMO the specific language should be secondary; i.e. the repository directory for a given type of network interface would contain C, C++, Java, Perl, and other code.
Confusing? Yes, somewhat. There would certainly be disjoints where there is no equivalent code, and the repository hierachy would have to be somewhat general. But doing so would have the implicit effect of encouraging porting, cross-platform development, and ultimately support sharing and development of GPL code in a manner that's not been done before.
Realizing that hacking C code is a wee different from gene sequencing, I still wonder if there's a new breed of hacker (pardon the pun) on the horizon. As many academic groups and biotech firms have shown, you can do a lot of research with minimal equipment. True, you can do a lot more with a wad of cash, but cash usually buys reduced time and not creativity. Following the thought through, won't we begin to see agri-hackers emerge as big firms put the squeeze on small producers? (Just as MS put the squeeze on the rest of the industry using bad-for-the-consumer products?)
There are already countless farmers and biologists who are hybridization experts, and I don't think it's a great leap to see them experimenting with Monsanto's latest genetically engineered product, and chatting with their virtual neighbors about it. Hybridization techniques are a far cry from laboratory engineering of specific genes, but still quite effective for guiding/preserving/producing desired traits. And gene sequencing no longer takes the army of researchers it once did. A little of both would reveal all manner of wonders -- Monsanto's NDAs be damned. All that's missing from the picture is an updated forum for sharing information (alt.agro.gene.warez? rec.hybrid.splice?) and some websites detailing how to do gene sequencing/splicing at home hosted by down-home agrihackers, hybrid-phreaks, and gene-crackers.
I'd venture a guess that in 10 years, Monsanto will have to develop gene encryption techniques in order to maintain their current business model, and we'll be looking at SETI@home or RC5-crack style distributed sequencing projects.
Tim's point about Kapor and Lotus 1-2-3 is very salient and timely. Think about it. Linux has reached a point where it threatens commercial products like NT for market space, forces OSS business models into the mainstream, pressures closed-source vendors to provide products for Linux (even if they don't want to participate in the OSS process), and generally returned a great deal of industry power to the hands of the consumer. The computing community is clearly ready for the next step -- the OSS killer app phase.
What is the killer app? Apache? Samba? There's no obvious answer, and Tim touches on this with his discussion of HTML. But he's still a little hung-up on the "web-based infoware" thing. I think the killer app that we're all waiting for isn't an app at all. The Linux/GNU/OSS movement has caused major shifts in the philosophical as well as computing landscape. The killer "app" is really the arrival of portable data. We've so commoditized the applications that it doesn't matter whether you're using Word, Wordperfect, Staroffice, Claris, a web-app, or who-knows-what else. What matters is how difficult it is to share information. Most productivity app vendors have decided to mimic MS Office 97 formats by providing converters, allowing in-format editing of MS-format documents, or using HTML as a native format, but these are only stopgaps. The next hurdle is to apply the OSS philosophy to content (data formats, interchage standards, protocols, translations), not just structure (operating systems, apps, web apps).
We're starting to see this a little, and it seems to be following XML. GNOME spreadsheets are stored in an XML format. User-friendly XML text editors such as XMetal and XML Spy are starting to show up for Windows. Oracle is starting to provide mainstream support for XML-based EDI. Consciously or not, we're beginning to think of common content formats as a global necessity. The problem, of course, is that these standards are typically built by glacially-slow concensus in a private industry forum. For example, the DTD for telecom information interchange that I was briefly involved with is maintained by the Information Products Interchange (IPI) subcommittee of the Telecommunications Industry Forum (TCIF), which is a subcommittee of the Alliance for Telecommunications Industry Solutions (ATIS). [See http://www.atis.org]
Buried in such a hierarchy, it's a wonder that the IPI's Telecommunications Interchange Markup standard (TIM, an XML-compliant SGML DTD) evolved at all. It's success is due primarily to the efforts of a few dedicated individuals. Sound familiar? This parallels the way that Linus et al manage updates to Linux kernel code. We're used to thinking of open source in terms of Linux and GNU software. Tim thinks of it as inclusive of web apps touches on interchange. We need to open that up to specifically include content. If you'll forgive the analogy, I think we've covered the nouns, and we have to think about the verbs -- apply OSS to the things we DO and not just the tools we use or places to do them. Open source organizational clearinghouses and listservs need to start providing for open source development of data formats and standards, not just apps. (Not to say that anyone working on OSS XML tools for Linux should slow down in the slightest!)
Those of us interested in data interchange, which includes anyone who ever shares so much as a text file, need to organize and communicate. If there's no standard for your data, develop one. If there is, contribute, review, and use it. (Think about harnessing all the wasted effort consumed by MS Office file format woes!) Don't let a vendor hold your data hostage in a proprietary format. The momentum behind Linux and other GNU software is driven by quality of the code and openness. Apply that to content, and the world will become a much better place.
I've tried very hard over the past few years to keep my SSN to myself, after a bad experience with a previous employer. My SSN showed up on my employee ID badge, my medical insurance card, my dental insurance card, my vision card, internal mailing labels, and my parking pass. The last item, of course, is what sent me over the edge. Not only is this grossly negligent, but there are numerous indirect ramifications. For example, my bank's account agreement specifically states that if I carry identifying numbers such as my SSN in my wallet with my ATM card, that (a) they consider it tantamount to writing the PIN on the card and (b) the bank is no longer liable/puts no limit on the loss you can incur if your card is stolen.
Unfortunately, US citizens are compelled to give their SSN (aka "TIN" -- taxpayer identification number, in IRS parlance) to financial institutions in the US. There is no way to avoid them using the number. However, other governmental agencies are prohibited from using the SSN as an identification number. Not so with private institutions.
I spent some time on the issue, found the federally-recognized generic SSNs (078-05-1120, and the series 987-65-4320 to -4329, typically used in instructions, advertisements, tv shows, etc) and made liberal use of them. When a unique number is critical, I ask the requester to assign a number that is unique _to_them_. For example, I have a number for all medical-related organizations and another for educational institutions at which I've taken classes recently, both distinct from my SSN. In this manner, I've compartmentalized the bases of information about myself so that it's much more difficult to develop an overall profile of me for invasive or marketing purposes.
I steadfastly refuse to give out my SSN for anything where it's not federally mandated. Yes, you can do it -- just be pleasant about it, and make sure the number you're using is unique to the organization so that you don't cause unnecessary confusion later on. If uniqueness isn't important, use one of the numbers above. On a related note, the home phone number printed on my checks is the bank branch's direct line, showing the same point: redirecting people usually works much better than stonewalling them.
One nice byproduct of this is that my junkmail levels have dropped to a very low level. Privacy is a relative concept, but it's not dead, and it's not irrelevant.
Since, as others have pointed out, the GPL makes no distinction between internal and external distribution (or between "product" and "program"), there appears to be no allowance for Corel's sublicensing actions. Thus (imho, ianal) the Corel Beta License is nonbinding on any code previously released under GPL.
BUT, hopefully this will be sorted out in a peaceful, businesslike manner. With ESR and others on the task, there's no need to burn Corel in effigy just because they're having growing pains as they transition from a closed-source model to an open one. Two steps forward and one step back is better than no steps at all.
As an earlier poster noted, "NSI want to add features so that people'll stay with them."
However, this is just the opposite of what I want from a service of this type. I'm about to register a domain name for personal use, and I've been perusing the various new options for doing so. Even looking past NSI's security gaffes, their service is instantly unattractive to me. This is because it's obvious that they don't understand the nature of the service they're selling.
Now that's a bold statement to make, but bear with me. Think of it from a sysadmin's career perspective. The typical sysadmin, when s/he does a perfect job, is completely invisible to the organization. When s/he screws up, everyone knows exactly where to send the blame. It's frequently a thankless job. So what happens? The sysadmin tried to increase the visibility of his or her positive performance by adding bells and whistles to the services which are offered. Frequently this takes the form of a new glitzy intranet page, new proprietary email system, or similar type of thing. Some of these may be well-received, and some (most, imho) may not, but the important thing to recognize is that the motivation for these projects is a lack of recognition for successful previous projects, and not an extension of core responsibilities. Unfortunately, it's just the nature of the job that stellar sysadmins are woefully underappreciated.
Likewise, NSI fails to regnize that its core business is one which will bring little recognition. If they do a great job, most of humanity won't know that they exist. That's just the nature of the beast. By offering these nifty add-on features such as free web email, they don't change the nature of that beast (their core business), they just open themselves up to a whole new set of criticisms. Any when they screw up, as evidenced by the recent security chasms, it makes them look like floundering amateurs.
Compare this to another internet-infrastructure-related company, Sun. Sun's recent ad campaign uses the "dot in.com" ditty. It may seem stupid, but I think it underscores that they know their business. They want to draw attention to the core things they do well and build on them. It's a subtle attempt to say "those things you take for granted to be reliable are our responsibility, so you should trust us with your further business." NSI tries to effect the same message by giving out free web-mail. Who do you think knows their business better and comes out ahead in the eyes of the masses? (Nevermind that the latter scheme was so poorly executed.)
On a personal level, it underscores that NSI's existence was dependent on monopoly control, not business expertise or technical self-awareness. The logical concusion is that I don't think NSI is long for this world, excepting radical changes in their business philosophies and practices. Thus the effect is to drive me away from purchasing their core services even if they had none of these web-mail security problems.
Looking at the agreement itself, it's pretty obvious that some legal department lackey did a search-and-replace using the last beta product license for who-knows-what. There are provisions that are obviously in violation with previous and superceding GPL licensing, but I suspect that it's an error, rather than a ploy to try and steal GPL code back into the proprietary world.
Corel will, in all likelyhood, quietly revise the license and try to remove the egg from their collective faces.
I have a friend with his US Social Security Number tattooed on his arm in Code 39 (3 of 9). He's had it since the late 80's which should document prior art of codes designed to be machine-readable.
If all that's required to document prior art is OCR-able text in a tattoo, I have some pictures of my grandparents' friends, who had identifying tattoos placed on them during a certain unsavory time period most Germans would like to forget. One could even argue that the triangle symbology was designed for optimized recognition, and thus was setting the stage for direct machine-readable identification tattoos.
Aftersci writes...though they apparently won't be throwing out all their Windows clients as if this is a really bad thing. Au contraire, this is a very good thing -- it shows that there is a carefully considered infrastructure decision being made here; one that focuses on the best use of technology where it's critical, and the best use of already-purchased infrastructure when it's in hand.
Sure, I'd like to see the France Telecom executives get so gung-ho about free/oss software that they all rush out and get tattoos of RMS' visage on their foreheads and name their children Linus, but it's much more important in the real world for them to make *visible*, careful, considered, long-term-view decisions. When they do so, it sets an example for the rest of the business world to follow (and takes people one step closer to realizing that Linux is generally a safe infrastructure choice). This is the sort of progress that will inspire PHBs in smaller arenas to say "Wow. Telcos are using Linux on the back end. Maybe I won't ignore my sysadmin the next time he starts talking about upgrading from NT to that Linux/SAMBA thing."
Funny, that -- at the SANS seminar on cyberterrorism in Seattle this week Alan demo'd just what you suggest -- a real-life picture of a startled-looking young man taken with his own webcam by a cracker using NetBus. His girlfriend is on the bed in the background, with both video & sound broadcast to the world. According to SANS, 60-70% of NT-based ISPs in the US have a serious NetBus infestation.
Go search for NetBus. Or BO. You chuckle. Someone else watches. And if you don't think it'll happen to you, you should look at my home router logs (on an unadvertised ip).
Not to beat a dead horse, but doesn't this point bring it full circle -- Isn't this requirement for public disclosure and open contribution what the GPL is all about? While I think there's a good argument to be made linking the very nature of free/open/GPL software development to the academic/open research publication exceptions in the silly US export laws, I hasten to add that I wouldn't want to be the test case.
Sources, please. Is it illegal for a US citizen to develop and freely distribute a Tcl/TK front-end to a non-US-developed command-line crypto package? I don't think so. If you know otherwise, please refer to the legal source. As other posters have noted, there is a distinction between working on something that would export-restricted from the US (chip design, hemp farming, certain software development, etc, which are not illegal), and working on something where the activity constitutes treason, which most certainly is illegal.
But IIRC, there is no provision in US code concerning export that prohibits me from leaving US territory and working as a consultant, even if the project I work on is crypto software that I could not export of I'd worked on it locally. Obviously there are other legal beartraps one could step on (working as a consultant developing nuclear missle targeting systems for China would probably result in an NSA-funded body cavity search as foreplay). However, outside of such obviously foolish and provocative activities (i.e. anything that could justify a treason charge), I don't believe there's any restriction on the export of cryptographic expertise contained in one's brain. If a US citizen travels to Brazil and works for a company producing a 1024-bit pgp-based email client, there's no US law broken. But there are two issues here: the items being transferred, and the transferring itself. I think there's a way to be safe from both perspectives.
If it is clear that the codebase resides outside of the US, and the US citizen contributes, then in principle the expertise is the only export from the country. Remember, it's not illegal for a US citizen to print out the code to a crypto program, take the resulting ream of paper on an airplane to Australia, and rekey it into a system upon arrival. Only exporting code in compilable or executable format is a violation of silly US law. By the same token (big disclaimer -- IANAL) a US citizen should be able to contribute to a foreign-based project legally by making sure the only tangible thing transferred internationally is knowhow. I.e. using ssh, the non-US-exportable item being developed never originates in the US.
Just to be sure that you've covered the transfer aspect as well, the work relationship also needs to be structured such that there never is an "export" event. One needs to make sure that the contribution takes the form of legal telecommuting to another country to perform work legally in that country. Even if you receive no other compensation than inclusion of one's name in a list of contributors.
IANAL. IANA export specialist. IAN even sure I know who I am.
(a) Red Hat being able to distinguish their product from marketplace lookalikes (i.e. the MacMillan boxed set and the like, and
(b) free distro's called "Blue Hat" (from IBM, of course), "Gnu Hat" (from Linux Central or Linux Mall), "Old Hat" (archives), etc., etc. Humor is an excellent marketing tool.
Two years you lasted at this place? You must be a saint. I hope and pray (in no particular direction) to work with people at patient and well-mannered as you.
However, every once in a while, a good tech explosion serves to bring a PHB back to earth. One PHB that I worked with had to endure 12 years of self-inflicted failures and embarassment in front of customers before he finally got a clue about being technically responsible when in the business of selling technology. What turned the tide? His only long-standing code guru finally snapped, gave him a dose of honesty that singed his eyebrows, resigned on the spot, and started his own immediately-successful company. Now if his accountant would snap, he'd have it made.
There's hope. But generally not enough for everyone.
It's a place where a new breed of agricultural technology is practiced. A woody vine plant (Autopatternalia Siliconus) was interbred with a temperate succulent fruit tree (Systemus Operandium). The resultant hybrid grows in a symbiotic relationship with a nutrient-providing ground fungus (Boot Lotus), and produces fully grown server system at various stages in the growing season.
Picked early, the fruit of this hybrid can be used as a console game systems and handhelds. Although the young, vigorous processing power of this spring harvest is impressive, the display capabilities are frequently of lower resolution due to lack of early-season sunlight. Certain strains of the hybrid produce fruit with gene deficiencies that bear a striking resemblance to the accelerated aging "Werner Syndrome" that occurs in humans. These fruit are typically labeled as Windows CE systems and shipped quickly so as to reduce the risk of the imminent spoilage or failure occurring while still in the vendor's stock. In contrast, however, other early-season fruit can be quite nice. The pea-pod-like UcLinux system (Homunculum Simmsocketii) is surprisingly edible and leaves a sweet aftertaste. Later versions have more well-developed visual processing, and are frequently marketed as 3com "Palm" and sometimes IBM products (Geekus Necessitatium).
When fully-grown, early summer servers show the distinctive markings resembling a black-tristed hydra logo, and are primarliy marketed by Microsoft, a Pacific Northwest grower that makes good use of the fertile valleys of Redmond. However, overproduction and lack of quality control in the Windows NT (Rebootus Idiotboxen) gardens over many years have led some to speculate that the soil lacks the proper nutrients, and that no amount of fertilizer will bring the product up to par.
In the opinion of many, the better options are the more mature mid-season products of organically-grown Linux (Pervasive Torvaldis), xBSD (Stabilus Unappreciatorum), and other related varieties. Widely regarded for their versatility and consistent quality, these products have only market difficulties to overcome. Organically-grown products frequently have visible blemishes that may turn away potential customers, but the quality and nutritional value of the fruit are rarely compromised.
Late-season harvests include the dark-greyish skinned Starfire system (Herkinprocessor Megagbuckus), which shows a distinctive 16-pointed Solaris bloom, and various (Monolithicus Neccesiconsultivus) of the IBM farms. Varietals are available from Hitachi, Fujitsu, SGI/Cray, NEC, and a host of others. Of particular note is the late-harvest Beowolf (Centiprocessorus Gnubiquitous) that can be made into an excellent ice wine.
Hope this helps.
Jon Fertilizer Consultant Xenobiotica's Olde-Tyme Server Farms
CE itself is in ROM. Can some wizard comment on the feasibility of replacing the ROM with EPROMs? (No chance of them being socketed, I'd venture.) Maybe they already are EPROMs? I would imagine that some WinCE device mfrs want to preserve their configuration options, if only to upgrade to a later patch level of WinCE. This would open the doors to embedding a certain other more appealing OS.
The results you point to aren't all that weird. My take on these responses is that there are a lot of VB developers who'd like to code for Linux, and they'd like to use their current skills. (I remember seeing a tool a while back that did a VB-to-Java translation, allowing VB programmers to shake off the chains and develop cross-platform apps.) BASIC language support in a Borland VIDE might allow a lot of these folks' skills to be portable.
You can run ASP on Linux. ChiliSoft's ChiliASP, I think. And Apache::ASP with modperl.
MS SQL Server needs all the help it can get, so a port to Linux might actually be in MS's favor. (!)
I too find it very encouraging that despite the obvious windows-developer slant, there's a strong interest in releasing free software. There's hope yet.
MS's reaction to unfuck.exe now appears to be incorrect -- it does not intercept the audio stream, but is a true crack. No D-A/A-D loss, not even any loss of compressed file size.
I wonder if MS's mistaken spin on this was intentional (i.e. make the crack seem as if it produces low-quality audio), or if they just sent a vacuous PR-drone to speak to the masses.
Slashdot Mirror
When I was in Sydney last year, I ran into some folks at an XML conference that were pushing the Royal Melbourne Institute of Technology's then-new all-online certificate and degree programs. The program seems pretty solid, and the University is a hotbed of XML work. They have since been marketing to me pretty hard, and both my conversations with them and the materials portray it as a no-bullshit all-web-based program for BS, MS, and PhD in technical fields. Check it out the online program here.
While it seems all well and good, can anyone who has actually attended a program there comment on it? RMIT seems more serious than the current wave of schools using the shovelware method of developing online course offerings. Is it as good as it appears?
Memory stick, phooey! And is it just me, or does Sony's prorietary "ATRAC3" music format sound suspiciously like "8-track v.3"?
:)
While I welcome several aspects of this (Sony teaming up with Palm instead of WinCE, motivation to boost Palm hardware cpu power, general competition), I'm a little disappointed that it'll push Palm further down a proprietary road. I'm simply not interested in buying into any technology that has hand-slapping of perceived-errant consumers built into it. No Sony memory sticks for me. Maybe my next PDA will be a Visor. But then again, the idea of playing 8-tracks with my Palm is strangely appealing...
[I put a bit of thought into this, so I've crossposted my comment from Forbes.]
Like many professionals reading this (I think I can safely speak for many at this level), I'm disappointed both by JP's behavior and methods of operation, and by the community response. While it's pretty clear that JP is far less experienced and far more vindictive than he represents, you have to give the guy some credit for standing up to a wall of immature criticism. For example, the lack of intelligent questions in yesterday's Slashdot interview was very disappointing; I'd have liked to see something along the lines of "What do you see as the next few steps in the evolution of remote NT cracking" or "What would you recommend as a baseline security configuration for deployment of a small XYZ-based ecommerce site?"
Of course, I'm the only one to blame for not posting these questions. Why did I not post them? Because previous experience tells me that the responses would be ill-researched and of little use. JP does not have anything new or interesting to offer in this arena. Perhaps that's a little hypocritical of me -- criticising the community for lack of reasonable questions when I failed to contribute. But then again, it's clear that the feeling was common. What a waste of community brain-cycles.
For the sake of argument, how can JP become a respected individual in the security arena? It's clear he's got a talent -- just not in the mechanics of system or network security. He's an excellent consciousness-raiser, even if his methods need some cleanup. (The comparison to Howard Stern was excellent.) Perhaps he would be a good addition to a security consultancy that has a lot of introverted systems gurus with good leadership and financial backing, but needs someone with basic knowledge and a talent for verbal evangelism. With the proper organizational guidance and support from a technical research team that actually knows its stuff, he could actually do some good in this world. As it stands, however, he's overextended the boundaries of his knowledge and talent, and brings the whole security community down by inciting the online and legal equivalent of schoolyard fistfights.
grey@enigma.mips4.com writes: I'm not sure what companies have to go throgh to get authorization to do electronic transfers by account number, but with abuses it could undoubtedly be revoked. One would hope it's fairly difficult to get and has high penalties for abuse...
Here's the criteria: A vendor goes to their bank, gives their bank your account number and bank routing number. If questioned, the vendor may have to sign a statement that they have your authorization on file, but nothing more. In common practice, there is no actual verification of your authorization -- the originating bank takes the initiator's statement as your authorization.
As for penalties, it appears that it's on the same level as writing a bad check. If the vendor makes enough unauthorized transactions, someone at that bank might slap their wrist -- and send them along to the next bank. Pathetic and sad, indeed. I used to work (long ago) as a banking MIS drone, yet the more I deal with that industry as a consumer, the more I'm consistently horrified by the endemic negligence and resistance to new knowledge.
Ater reading a gob o' comments, it seems like most semi-aware folks are disgusted by the blithely ignorant ways of the US patent office. Few, however, have ideas about what to do. Lobbying is good. Opening the eyes of the mainstream media is good (the ABC News (I think) coverage on gene patents the other day was fantastic). But it's not enough.
/. is somewhat constructive, but it seems to me that that's a step short of a public discussion forum dedicated to discovery of prior art. Instead of lamenting about how bad the patent process is on /., howzabout a place where every article is a ridiculous patent, and the typical reply is "check out XXXX and YYY which both did this years before LudicrousPatentFiler Inc did." Moderation categories could include "prior art," "common knowledge," "other patent infringment," "nonoperative," or -- god forbid -- "valid."
/source go, anyway? Think I could run such a thing on a 384k dsl line?
But how about more focused public discussion? Tossing these up on
The mere existence of such a community-led patent debunker might make the average company a bit more careful about throwing several thousand dollars at a patent that gets invalidated in an hour or two.
Where did that
Jon (xeno*wolfenet!com)
Since you brought up the spectre of financial institutions' ideas on security, the following recent personal experience should provide some insight into the current state of thinking among some in the US:
I applied for life insurance with a major reputable company, and was accepted. Their typical m.o. is to set up automatic withdrawal, but I declined and wrote them a check for a full year premium (several hundred dollars). About a week later, I received a confirmation from them that they had automatically withdrawn the full amount using the account number taken off my check AND cashed my check. I immediately called to ask why they had done this, and they were gracious enough to immediately reverse the automatic withdrawal by making another unauthorized transaction to my account -- this time a deposit.
I'm a little irritated at the insurance company, but I was infuriated that my bank allowed these multiple unauthorized transactions. So I inquired further. It turns out that my bank (Washington Mutual, based in Seattle) does not know the difference between identification and authorization! Their position is that I gave authorization to the insurance company by giving them my account number, which was printed on the bottom of my check. I informed the bank that (a) in fact I had not given the number, but that it was taken from my check, and (b) that the number is identification, not authorization.
Neither of these facts fazed them one bit. In numerous calls and personal visits (I happen to be working near their headquarters), I could not find a single individual who understood that there was a difference between identification and authorization. What does this mean? IMHO, it means that there is no interest in even password-level security. Sure, they understand that when a customer looks at their account summary online they need to have a name and password, but when Joe Random fishes my check stubs out of the shredder and learns my account identity, the bank will duly process every one of his automatic withdrawal transactions without authorization. The kicker is that WAMU informed me that there is no way to refuse this type of transaction -- if I have an account with them, I *must* accept this idiotic risk. Needless to say, I'm investigating whether my credit union has a similarly brain-dead policy. (I'm afraid, however, that this may be the result of nationwide transaction policy -- perhaps even mandated by Federal Reserve rules.)
With respect to the main topic, this has some frightening implications. My bank not only allows informational access, but transactional access, without real authorization. Ok, so someone can steal money from me and my bank officially considers me to be at fault. This sort of SNAFU won't necessarily do me in. But what happens if online access to medical information takes the same route? What if I can not only inquire as to my own information, but I have transactional access as well (such as requesting medication refills, changing my ship-to-address, reporting my progress in treatment, etc etc)? This could kill me -- literally. I applaud the effort to provide strong security, and if it's offered, I'll opt into it. But right now I'm concerned about just basic authentication.
Jon
The question that immediately comes to mind is how to organize the code. CPAN is PERL-specific, and other repositories tend to be similar in terms of supporting a single language.
.02
On the other hand, the purpose of the proposed repository is to support the distribution, improvement, and archiving of GPL code. IHMO the specific language should be secondary; i.e. the repository directory for a given type of network interface would contain C, C++, Java, Perl, and other code.
Confusing? Yes, somewhat. There would certainly be disjoints where there is no equivalent code, and the repository hierachy would have to be somewhat general. But doing so would have the implicit effect of encouraging porting, cross-platform development, and ultimately support sharing and development of GPL code in a manner that's not been done before.
-just my
Realizing that hacking C code is a wee different from gene sequencing, I still wonder if there's a new breed of hacker (pardon the pun) on the horizon. As many academic groups and biotech firms have shown, you can do a lot of research with minimal equipment. True, you can do a lot more with a wad of cash, but cash usually buys reduced time and not creativity. Following the thought through, won't we begin to see agri-hackers emerge as big firms put the squeeze on small producers? (Just as MS put the squeeze on the rest of the industry using bad-for-the-consumer products?)
There are already countless farmers and biologists who are hybridization experts, and I don't think it's a great leap to see them experimenting with Monsanto's latest genetically engineered product, and chatting with their virtual neighbors about it. Hybridization techniques are a far cry from laboratory engineering of specific genes, but still quite effective for guiding/preserving/producing desired traits. And gene sequencing no longer takes the army of researchers it once did. A little of both would reveal all manner of wonders -- Monsanto's NDAs be damned. All that's missing from the picture is an updated forum for sharing information (alt.agro.gene.warez? rec.hybrid.splice?) and some websites detailing how to do gene sequencing/splicing at home hosted by down-home agrihackers, hybrid-phreaks, and gene-crackers.
I'd venture a guess that in 10 years, Monsanto will have to develop gene encryption techniques in order to maintain their current business model, and we'll be looking at SETI@home or RC5-crack style distributed sequencing projects.
- Jon (sticking to certified organic food)
Tim's point about Kapor and Lotus 1-2-3 is very salient and timely. Think about it. Linux has reached a point where it threatens commercial products like NT for market space, forces OSS business models into the mainstream, pressures closed-source vendors to provide products for Linux (even if they don't want to participate in the OSS process), and generally returned a great deal of industry power to the hands of the consumer. The computing community is clearly ready for the next step -- the OSS killer app phase.
What is the killer app? Apache? Samba? There's no obvious answer, and Tim touches on this with his discussion of HTML. But he's still a little hung-up on the "web-based infoware" thing. I think the killer app that we're all waiting for isn't an app at all. The Linux/GNU/OSS movement has caused major shifts in the philosophical as well as computing landscape. The killer "app" is really the arrival of portable data. We've so commoditized the applications that it doesn't matter whether you're using Word, Wordperfect, Staroffice, Claris, a web-app, or who-knows-what else. What matters is how difficult it is to share information. Most productivity app vendors have decided to mimic MS Office 97 formats by providing converters, allowing in-format editing of MS-format documents, or using HTML as a native format, but these are only stopgaps. The next hurdle is to apply the OSS philosophy to content (data formats, interchage standards, protocols, translations), not just structure (operating systems, apps, web apps).
We're starting to see this a little, and it seems to be following XML. GNOME spreadsheets are stored in an XML format. User-friendly XML text editors such as XMetal and XML Spy are starting to show up for Windows. Oracle is starting to provide mainstream support for XML-based EDI. Consciously or not, we're beginning to think of common content formats as a global necessity. The problem, of course, is that these standards are typically built by glacially-slow concensus in a private industry forum. For example, the DTD for telecom information interchange that I was briefly involved with is maintained by the Information Products Interchange (IPI) subcommittee of the Telecommunications Industry Forum (TCIF), which is a subcommittee of the Alliance for Telecommunications Industry Solutions (ATIS). [See http://www.atis.org]
Buried in such a hierarchy, it's a wonder that the IPI's Telecommunications Interchange Markup standard (TIM, an XML-compliant SGML DTD) evolved at all. It's success is due primarily to the efforts of a few dedicated individuals. Sound familiar? This parallels the way that Linus et al manage updates to Linux kernel code. We're used to thinking of open source in terms of Linux and GNU software. Tim thinks of it as inclusive of web apps touches on interchange. We need to open that up to specifically include content. If you'll forgive the analogy, I think we've covered the nouns, and we have to think about the verbs -- apply OSS to the things we DO and not just the tools we use or places to do them. Open source organizational clearinghouses and listservs need to start providing for open source development of data formats and standards, not just apps. (Not to say that anyone working on OSS XML tools for Linux should slow down in the slightest!)
Those of us interested in data interchange, which includes anyone who ever shares so much as a text file, need to organize and communicate. If there's no standard for your data, develop one. If there is, contribute, review, and use it. (Think about harnessing all the wasted effort consumed by MS Office file format woes!) Don't let a vendor hold your data hostage in a proprietary format. The momentum behind Linux and other GNU software is driven by quality of the code and openness. Apply that to content, and the world will become a much better place.
Jon
I've tried very hard over the past few years to keep my SSN to myself, after a bad experience with a previous employer. My SSN showed up on my employee ID badge, my medical insurance card, my dental insurance card, my vision card, internal mailing labels, and my parking pass. The last item, of course, is what sent me over the edge. Not only is this grossly negligent, but there are numerous indirect ramifications. For example, my bank's account agreement specifically states that if I carry identifying numbers such as my SSN in my wallet with my ATM card, that (a) they consider it tantamount to writing the PIN on the card and (b) the bank is no longer liable/puts no limit on the loss you can incur if your card is stolen.
Unfortunately, US citizens are compelled to give their SSN (aka "TIN" -- taxpayer identification number, in IRS parlance) to financial institutions in the US. There is no way to avoid them using the number. However, other governmental agencies are prohibited from using the SSN as an identification number. Not so with private institutions.
I spent some time on the issue, found the federally-recognized generic SSNs (078-05-1120, and the series 987-65-4320 to -4329, typically used in instructions, advertisements, tv shows, etc) and made liberal use of them. When a unique number is critical, I ask the requester to assign a number that is unique _to_them_. For example, I have a number for all medical-related organizations and another for educational institutions at which I've taken classes recently, both distinct from my SSN. In this manner, I've compartmentalized the bases of information about myself so that it's much more difficult to develop an overall profile of me for invasive or marketing purposes.
I steadfastly refuse to give out my SSN for anything where it's not federally mandated. Yes, you can do it -- just be pleasant about it, and make sure the number you're using is unique to the organization so that you don't cause unnecessary confusion later on. If uniqueness isn't important, use one of the numbers above. On a related note, the home phone number printed on my checks is the bank branch's direct line, showing the same point: redirecting people usually works much better than stonewalling them.
One nice byproduct of this is that my junkmail levels have dropped to a very low level. Privacy is a relative concept, but it's not dead, and it's not irrelevant.
If I may quote from the GPL: 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.
Since, as others have pointed out, the GPL makes no distinction between internal and external distribution (or between "product" and "program"), there appears to be no allowance for Corel's sublicensing actions. Thus (imho, ianal) the Corel Beta License is nonbinding on any code previously released under GPL.
BUT, hopefully this will be sorted out in a peaceful, businesslike manner. With ESR and others on the task, there's no need to burn Corel in effigy just because they're having growing pains as they transition from a closed-source model to an open one. Two steps forward and one step back is better than no steps at all.
Jon
As an earlier poster noted, "NSI want to add features so that people'll stay with them."
.com" ditty. It may seem stupid, but I think it underscores that they know their business. They want to draw attention to the core things they do well and build on them. It's a subtle attempt to say "those things you take for granted to be reliable are our responsibility, so you should trust us with your further business." NSI tries to effect the same message by giving out free web-mail. Who do you think knows their business better and comes out ahead in the eyes of the masses? (Nevermind that the latter scheme was so poorly executed.)
However, this is just the opposite of what I want from a service of this type. I'm about to register a domain name for personal use, and I've been perusing the various new options for doing so. Even looking past NSI's security gaffes, their service is instantly unattractive to me. This is because it's obvious that they don't understand the nature of the service they're selling.
Now that's a bold statement to make, but bear with me. Think of it from a sysadmin's career perspective. The typical sysadmin, when s/he does a perfect job, is completely invisible to the organization. When s/he screws up, everyone knows exactly where to send the blame. It's frequently a thankless job. So what happens? The sysadmin tried to increase the visibility of his or her positive performance by adding bells and whistles to the services which are offered. Frequently this takes the form of a new glitzy intranet page, new proprietary email system, or similar type of thing. Some of these may be well-received, and some (most, imho) may not, but the important thing to recognize is that the motivation for these projects is a lack of recognition for successful previous projects, and not an extension of core responsibilities. Unfortunately, it's just the nature of the job that stellar sysadmins are woefully underappreciated.
Likewise, NSI fails to regnize that its core business is one which will bring little recognition. If they do a great job, most of humanity won't know that they exist. That's just the nature of the beast. By offering these nifty add-on features such as free web email, they don't change the nature of that beast (their core business), they just open themselves up to a whole new set of criticisms. Any when they screw up, as evidenced by the recent security chasms, it makes them look like floundering amateurs.
Compare this to another internet-infrastructure-related company, Sun. Sun's recent ad campaign uses the "dot in
On a personal level, it underscores that NSI's existence was dependent on monopoly control, not business expertise or technical self-awareness. The logical concusion is that I don't think NSI is long for this world, excepting radical changes in their business philosophies and practices. Thus the effect is to drive me away from purchasing their core services even if they had none of these web-mail security problems.
Looking at the agreement itself, it's pretty obvious that some legal department lackey did a search-and-replace using the last beta product license for who-knows-what. There are provisions that are obviously in violation with previous and superceding GPL licensing, but I suspect that it's an error, rather than a ploy to try and steal GPL code back into the proprietary world.
Corel will, in all likelyhood, quietly revise the license and try to remove the egg from their collective faces.
I have a friend with his US Social Security Number tattooed on his arm in Code 39 (3 of 9). He's had it since the late 80's which should document prior art of codes designed to be machine-readable.
If all that's required to document prior art is OCR-able text in a tattoo, I have some pictures of my grandparents' friends, who had identifying tattoos placed on them during a certain unsavory time period most Germans would like to forget. One could even argue that the triangle symbology was designed for optimized recognition, and thus was setting the stage for direct machine-readable identification tattoos.
Aftersci writes ...though they apparently won't be throwing out all their Windows clients as if this is a really bad thing. Au contraire, this is a very good thing -- it shows that there is a carefully considered infrastructure decision being made here; one that focuses on the best use of technology where it's critical, and the best use of already-purchased infrastructure when it's in hand.
Sure, I'd like to see the France Telecom executives get so gung-ho about free/oss software that they all rush out and get tattoos of RMS' visage on their foreheads and name their children Linus, but it's much more important in the real world for them to make *visible*, careful, considered, long-term-view decisions. When they do so, it sets an example for the rest of the business world to follow (and takes people one step closer to realizing that Linux is generally a safe infrastructure choice). This is the sort of progress that will inspire PHBs in smaller arenas to say "Wow. Telcos are using Linux on the back end. Maybe I won't ignore my sysadmin the next time he starts talking about upgrading from NT to that Linux/SAMBA thing."
Funny, that -- at the SANS seminar on cyberterrorism in Seattle this week Alan demo'd just what you suggest -- a real-life picture of a startled-looking young man taken with his own webcam by a cracker using NetBus. His girlfriend is on the bed in the background, with both video & sound broadcast to the world. According to SANS, 60-70% of NT-based ISPs in the US have a serious NetBus infestation.
Go search for NetBus. Or BO. You chuckle. Someone else watches. And if you don't think it'll happen to you, you should look at my home router logs (on an unadvertised ip).
Not to beat a dead horse, but doesn't this point bring it full circle -- Isn't this requirement for public disclosure and open contribution what the GPL is all about? While I think there's a good argument to be made linking the very nature of free/open/GPL software development to the academic/open research publication exceptions in the silly US export laws, I hasten to add that I wouldn't want to be the test case.
Sources, please. Is it illegal for a US citizen to develop and freely distribute a Tcl/TK front-end to a non-US-developed command-line crypto package? I don't think so. If you know otherwise, please refer to the legal source. As other posters have noted, there is a distinction between working on something that would export-restricted from the US (chip design, hemp farming, certain software development, etc, which are not illegal), and working on something where the activity constitutes treason, which most certainly is illegal.
But IIRC, there is no provision in US code concerning export that prohibits me from leaving US territory and working as a consultant, even if the project I work on is crypto software that I could not export of I'd worked on it locally. Obviously there are other legal beartraps one could step on (working as a consultant developing nuclear missle targeting systems for China would probably result in an NSA-funded body cavity search as foreplay). However, outside of such obviously foolish and provocative activities (i.e. anything that could justify a treason charge), I don't believe there's any restriction on the export of cryptographic expertise contained in one's brain. If a US citizen travels to Brazil and works for a company producing a 1024-bit pgp-based email client, there's no US law broken. But there are two issues here: the items being transferred, and the transferring itself. I think there's a way to be safe from both perspectives.
If it is clear that the codebase resides outside of the US, and the US citizen contributes, then in principle the expertise is the only export from the country. Remember, it's not illegal for a US citizen to print out the code to a crypto program, take the resulting ream of paper on an airplane to Australia, and rekey it into a system upon arrival. Only exporting code in compilable or executable format is a violation of silly US law. By the same token (big disclaimer -- IANAL) a US citizen should be able to contribute to a foreign-based project legally by making sure the only tangible thing transferred internationally is knowhow. I.e. using ssh, the non-US-exportable item being developed never originates in the US.
Just to be sure that you've covered the transfer aspect as well, the work relationship also needs to be structured such that there never is an "export" event. One needs to make sure that the contribution takes the form of legal telecommuting to another country to perform work legally in that country. Even if you receive no other compensation than inclusion of one's name in a list of contributors.
IANAL. IANA export specialist. IAN even sure I know who I am.
Dang. I was actually looking forward to:
(a) Red Hat being able to distinguish their product from marketplace lookalikes (i.e. the MacMillan boxed set and the like, and
(b) free distro's called "Blue Hat" (from IBM, of course), "Gnu Hat" (from Linux Central or Linux Mall), "Old Hat" (archives), etc., etc. Humor is an excellent marketing tool.
Two years you lasted at this place? You must be a saint. I hope and pray (in no particular direction) to work with people at patient and well-mannered as you.
However, every once in a while, a good tech explosion serves to bring a PHB back to earth. One PHB that I worked with had to endure 12 years of self-inflicted failures and embarassment in front of customers before he finally got a clue about being technically responsible when in the business of selling technology. What turned the tide? His only long-standing code guru finally snapped, gave him a dose of honesty that singed his eyebrows, resigned on the spot, and started his own immediately-successful company. Now if his accountant would snap, he'd have it made.
There's hope. But generally not enough for everyone.
It's a place where a new breed of agricultural technology is practiced. A woody vine plant (Autopatternalia Siliconus) was interbred with a temperate succulent fruit tree (Systemus Operandium). The resultant hybrid grows in a symbiotic relationship with a nutrient-providing ground fungus (Boot Lotus), and produces fully grown server system at various stages in the growing season.
Picked early, the fruit of this hybrid can be used as a console game systems and handhelds. Although the young, vigorous processing power of this spring harvest is impressive, the display capabilities are frequently of lower resolution due to lack of early-season sunlight. Certain strains of the hybrid produce fruit with gene deficiencies that bear a striking resemblance to the accelerated aging "Werner Syndrome" that occurs in humans. These fruit are typically labeled as Windows CE systems and shipped quickly so as to reduce the risk of the imminent spoilage or failure occurring while still in the vendor's stock. In contrast, however, other early-season fruit can be quite nice. The pea-pod-like UcLinux system (Homunculum Simmsocketii) is surprisingly edible and leaves a sweet aftertaste. Later versions have more well-developed visual processing, and are frequently marketed as 3com "Palm" and sometimes IBM products (Geekus Necessitatium).
When fully-grown, early summer servers show the distinctive markings resembling a black-tristed hydra logo, and are primarliy marketed by Microsoft, a Pacific Northwest grower that makes good use of the fertile valleys of Redmond. However, overproduction and lack of quality control in the Windows NT (Rebootus Idiotboxen) gardens over many years have led some to speculate that the soil lacks the proper nutrients, and that no amount of fertilizer will bring the product up to par.
In the opinion of many, the better options are the more mature mid-season products of organically-grown Linux (Pervasive Torvaldis), xBSD (Stabilus Unappreciatorum), and other related varieties. Widely regarded for their versatility and consistent quality, these products have only market difficulties to overcome. Organically-grown products frequently have visible blemishes that may turn away potential customers, but the quality and nutritional value of the fruit are rarely compromised.
Late-season harvests include the dark-greyish skinned Starfire system (Herkinprocessor Megagbuckus), which shows a distinctive 16-pointed Solaris bloom, and various (Monolithicus Neccesiconsultivus) of the IBM farms. Varietals are available from Hitachi, Fujitsu, SGI/Cray, NEC, and a host of others. Of particular note is the late-harvest Beowolf (Centiprocessorus Gnubiquitous) that can be made into an excellent ice wine.
Hope this helps.
Jon
Fertilizer Consultant
Xenobiotica's Olde-Tyme Server Farms
CE itself is in ROM. Can some wizard comment on the feasibility of replacing the ROM with EPROMs? (No chance of them being socketed, I'd venture.) Maybe they already are EPROMs? I would imagine that some WinCE device mfrs want to preserve their configuration options, if only to upgrade to a later patch level of WinCE. This would open the doors to embedding a certain other more appealing OS.
The results you point to aren't all that weird. My take on these responses is that there are a lot of VB developers who'd like to code for Linux, and they'd like to use their current skills. (I remember seeing a tool a while back that did a VB-to-Java translation, allowing VB programmers to shake off the chains and develop cross-platform apps.) BASIC language support in a Borland VIDE might allow a lot of these folks' skills to be portable.
You can run ASP on Linux. ChiliSoft's ChiliASP, I think. And Apache::ASP with modperl.
MS SQL Server needs all the help it can get, so a port to Linux might actually be in MS's favor. (!)
I too find it very encouraging that despite the obvious windows-developer slant, there's a strong interest in releasing free software. There's hope yet.
MS's reaction to unfuck.exe now appears to be incorrect -- it does not intercept the audio stream, but is a true crack. No D-A/A-D loss, not even any loss of compressed file size.
I wonder if MS's mistaken spin on this was intentional (i.e. make the crack seem as if it produces low-quality audio), or if they just sent a vacuous PR-drone to speak to the masses.