Well, aesthetic reasons aside (because the thought of running NT under linux is aesthetically unappealing...), I am inclined to say "because you can".
This from a guy who saw vmware and immediately wanted to know if you can run a vmware inside a vmware (and how deeply they can be nested)... why? because you can!
Back when I worked in a Solaris shop I would go hunting for an easy-to-install distribution of a common utility (pick your favorite) and would see hundreds of lines in my search that all contained "linux" in them somewhere, which invariably meant a (to get them going on Solaris) a recompile, a failure, a tweak of headers and makefiles, a recompile, a less-than-perfect install, etc.
Sun wants to leverage that same code base for Solaris users (potentially to stop future user- base drain to Linux). The first step (the easy one) is to do it for the x86 platform where no machine code translation has to be done. Now, the next step is to make it work on the Ultras. Then you get all the big-$$$ benefits of Solaris boxen, with the no-$$$ benefits of open source code ready to run on Linux boxen. Sounds like a no-brainer to me.
I can compress a whole cd to a 100k file with no loss Wanna bet? Let me create 650Mb's of prime numbers and see if you can get it down to 100k with no loss. You may be able to compress "a cd" down to that small, but you can't compress any cd down to that size. If you can then for what should be obvious reasons your brain is worth far too much to risk posting silly comments on slashdot (in case The Man is reading).
I stand corrected... forgive my mistake. Back in '96 (don't laugh) I kept very good tabs on what was going on with Intel and its competitors regarding chip technology, with help from friends placed well at Intel (who would surely like to remain anonymous). At the time Merced was described as "essentially RISC" when compared with the CISC systems then being put out (and still being put out) by Intel. Over the past years I kept less abreast of the impending technologies (having moved my focus to more software development, and much of that *not* on Intel systems), but at least kept aware of scheduled *releases* and some of the current Intel technology. I clearly missed the IA64 move (talk about head in the sand) on which I have justed started to catch up, and hence the "RISC" discussion above.
The basis of my argument still stands, but the compilers will be harder to write, and I see now why there are some delays. Micro$oft does claim to have a 64-bit windows running on a Merced simulator (like that isn't a bald-faced lie, judging by other orthogonal press releases coming out of Redmond). I still firmly contend that the current marketing infrastructure for Intel's products will change if it cannot handle the responbilities of making money in Intel's Brave New World. etc., etc., etc.
Intel has been plagued for a decade by backwards compatibility with a poorly designed CISC chip with one of the poorest memory subsystem designs still in current use. The amount of juice which can be squeezed from the '86 lemon is limited and it is a testament to Intel's determination (some would say stubbornness or stupidity) that they have been able to make this architecture a profitable industry standard (of course the more cynical (myself included on the occasional lonely night) might chalk this up as a testament to the power of a tightly run monopoly).
Merced is a necessity if Intel wants to stay profitable in the face of not only Moore's Law but AMD and other not-so-dark horses. This chip has been designed for the most part for years. The compilers have been under development for years as well -- anyone who thinks otherwise doesn't know how Intel does business.
A company which has the resources to write compilers for superscalar CISC with pipelining, data forwarding, bizarre MMX registers/instructions, virtual '86s while maintaining backwards compatibility with the original broken design will find writing a new compiler for a freshly designed clean RISC system a wonderful relief. The amount of openly available published research in the RISC compiler community is significant, and Intel has the bucks to hire more gurus on the topic if they need them.
Marketing... It pains me to see so many people assume that "they way it is" is "the only way it can work". This is the same fallacious thinking that makes it painful to watch any Hollywood movie about time travel or the contact of our civilization with another (I think Indpendence Day may be the flagship example of this) -- the way we Americans do things in this day and age is superior to the way any other conceivable society could do them. Cultural ignorance and arrogance.
This sort of thinking comes up quite often in discussions of why "Windows will be here forever" and now appears here in a discussion of Intel's marketing plan for Merced. The truth of the matter is that (1) Intel wants the market to change -- they have been burdened with the '86 albatross for far too long, and (2) the market will change. Initially we hardware power users, systems hackers, and speed/systems freaks will jump on Merced because it is a better chip than a crappy CISC chip on steroids. The chipsets to run the chips will be there, and at least some variation in motherboard configurations. Dell/Compaq/Gateway will be able to sell a Merced system.
If, as Intel puts more of its weight behind Merced (and more applications are brought to Merced) the current distribution system cannot change their marketing model to take advantage of the new configurations which will be possible and then *desired*, then someone will step up to make the new money by providing them. Because it's done a certain way now doesn't mean that that is the only way (I reiterate at the risk of sounding pedantic). This industry moves too fast to coddle companies which have become too large to steer effectively.
The distribution channels for these systems, and multi-processor systems, will develop and may not include the current Big Players in the market. In addition, as Intel hopes, if AMD et al cannot create a chip to compete with Merced, and cannot anchor the market on the '86-type chips, they may also find themselves too big to steer out of the way of the Intel truck.
Be careful. Merced could be a swan song for Intel, but I think it is more likely their Excalibur.
I agree with your underlying premise that user education is one of the main problems in this type of situation.
Implying that VBA is a panacea, and that one day Linux is going to require a VBA-clone (at least as regards functionality) is patent bullshit. The functionality is present already in java/CORBA/Gtk/Tk/Perl/C++/OpenGL/Motif/Tcl/python /script_fu/etc. in the powerful applications in current wide use. You make the fallacious unspoken assumption that bloated applications (similar to word/excel/wordperfect/photoshop/access/VB/etc.) are a necessity to the success of Linux. To state it more plainly you assume that for Linux to be successful it must be just like Microsoft is now (in which case why choose one over the other) -- literally that Windows is the only viable solution for computing. To that I say, why should a descendant of the systems from which MS products are so blatantly derivative attempt to close the circle and mimic the poor imitation?
The functionality in *nix (Linux included) as regards interoperability and in-application programmability has historically so far exceeded (for nearly a decade) the laughable attempts MS has made in this area that your supporting argument is ludicrous.
The unfortunate downside is that, as bloatware vendors migrate their products to Linux to attract the $'s of the clueless masses they will invariably take the easy course: using the same broken solutions that sold on a faulty mass-produced system instead of attempting to re-innovate to achieve the "right" solution. The warning is legitimate but should read: VBA is another "broken whore" (as a lead QA tester for a major networking company once described WinNT to me), and any further UserFriendly scripting solution on *nix should be developed with attention to correctness (security) than attention to bottom-line.
The beauty of the OpenSource paradigm is that a scripting solution (if the community has the need for yet another) will be developed which addresses these issues.
roundeye
top 10 experiments to conduct on Sony Dog
on
Robotic Dogs
·
· Score: 4
For the marketing representatives of Sony reading this list I am officially making a proposal for experimentation with this groundbreaking AI technology and will require eleven (11) Sony(tm) Dogs(tm) in order to conduct the following important experiments:
10 - "Identity Crisis" - one week of acclimation training to dog's given name "Rambo" with establishment of "his territory", "his chores", and "his spiked collar". After week one dog will be referred to by the name "Prissy", shown "her pink bow", and reprimanded on "violations of Rambo's territory." "Rambo is a good dog. Prissy is a bad dog." Prissy will have no "territory". Rambo's emminent angry return will be prophecied more and more frequently.
9 - "Navigation" - Dog will be told that my apartment is "it's wonderful home." Dog will be taken to the sidewalk and will be told to "come home!". On the next day dog will be taken to the end of the block and told to "come home!". On the third day Dog will be taken to the edge of the neighborhood and be told to "come home!". On the fourth day Dog will be placed in the luggage hold of a Greyhound bus bound for El Paso, TX and told to "come home!"
8 - "New Dog, New Trick!" - Dog will be taught to fetch Heineken from refrigerator, being rewarded after each fetch. After one week, Dog's legs will be removed and replaced with standard grocery shopping cart wheels, floor will be waxed and Dog will be told to "fetch beer". Pictures of Dog from experiment #9 being placed under bus with "El Paso, TX" on destination placard will be shown for motivation.
7 - "Schizoid" - Dog will be trained to go to front door upon utterance of phrase "go to front door", and trained to go to back door upon utterance of phrase "go to back door". Dog's vocal recorder will be programmed to play sound clip of experimenter saying "go to back door" when dog arrives at front door. Dog's vocal recorder will be programmed to play sound clip of experimenter saying "go to front door" when dog arrives at back door. Experimenter utters command "go to front door."
6 - "Da pimp" - Dog will be shown selections from an extensive catalogue of bestiality films. Dog will be dressed in lingerie and placed on a street corner in a depressed local neighborhood. Dog will be instructed that "Pimp daddy betta get all his cash or you ain't nobody's bitch no more!"
5 - "Doggy Style" - Dog will be shown old Lassie reruns where Lassie swims to save Timmy. Dog will be transported via pontoon boat with mannequin labelled "Timmy" to middle of sizeable community reservoir. Timmy will be thrown overboard. Dog will be thrown overboard. Pontoon boat will return to shore to record observations.
4 - "Silicon brain, Iron Will" - Dog's mobility circuits will be disabled. Dog will be placed in front of a television, in an otherwise empty room, which will play a continuous tape-loop of "Young Einstein" starring Yahoo Serious. Dog will be wired to the charging system to provide continuous recharging. At the end of one month the Dog will remain locked in this room with mobility circuits re-activated.
3 - "Nuremberg" - Dog will be placed on trial for "crimes against humanity" and sentenced to execution by Monster Truck. A lengthy but fruitless appeals process will be conducted with experimenter playing the roles of public defender and presiding judge. Dog will be executed after dramatic "Dead Dog Walking" march to driveway.
2 - "Franken-tug" - Two Dog's will be trained to "fetch". Both Dog's will be disassembled and their front halves joined back to back. "Dog" will be reactivated and told to "fetch".
1 - "MSCSE" - Dog will be trained to pass the Microsoft Certified Software Engineer Exam. After receiving certification, Dog will apply to Redmond, WA headquarters as a "Lead Developer". Salary and unavoidable performance bonuses will be contributed to the Free Software Foundation.
ABC news reported this morning on their radio coverage (as lately as 10pm EST) that the FBI had traced the emergence of the virus to somewhere in Europe, with no mention of AOL, unique IDs, etc. I would say that ZD and ABC are reporting different information. Is the FBI throwing nonsense to ABC? Does the FBI know about the AOL trace (one would think so)?
Well, whatever. My linux boxen somehow don't appear in the "Address Books" of MS-only users, so I guess that's a blessing. I'd hate to have to read the virus document safely and just delete it;)
roundeye
fine example of classic propaganda techniques
on
Slate Takes on Linux
·
· Score: 5
The lady's install article was almost fair, and an echo of things heard in the highly flamed Katz install dilemma (I think she faired much more admirably than Katz actually).
The "techie" article was, IMHO, one of the more disturbing pieces of propaganda that I have seen as of late. It reminds me of "Purple Heart" - a WWII-era propaganda movie (one of *ours* folks) aimed at the Japanese culture and war machine.
By the second paragraph he is already setting out to portray Linux as confusing, different, and something that Windows people don't have any contact with. It appears to me that he is targeting the average Windows user who has no contact with Linux (to their knowledge) and who wants their questions settled in an article from someplace safe. He makes Linux immediately seem confusing and alien. Good strategy. Many of his finer facts are wrong, but within the realm of plausible deniability. He sets out immediately the "good guy/bad guy" duality (Linux is made by one guy instead of a faceless monolith, but really it's made by a bunch of faceless organizations who can't decide on names. Shreds of truth on both counts, but the second one is where he puts his emphasis) he uses throughout the rest of the article to establish "objectivity" while he trashes the system.
He continues on to draw upon the party line to subtly attack the FSF's motives. Far be it from me to side with a Microsoft instrument, but I have to agree that I don't expect to see sellable software vanish from the world in my lifetime, but I don't think that's the point. I'll let the debaters rage on that one -- I just enjoy having a choice, being able to use good software that I can muck around in with the code.
His description of Linux as merely a kernel to which one could add a windowing system, etc. Is the first point where I began to get disturbed and decided to post a response. The author slips from debatable propaganda/FUD and slight confusion of facts into a not-so-subtle attack on the (debatable) weaknesses of Linux with the implication of "...and so the thing's useless. Go now back to your homes and play with your Windows boxes and enjoy your hair." You are free to go now. The verdict is in.
Linux *is* short of application software when compared to the Windows software base. To split hairs one can install Linux without X, but if a GUI is important to you then you would install it. The implication that significant extra work or (as with NT for example) extra purchases must be performed to install the OS with what should be considered "standard" features is another example of fine propaganda techniques. The implication that the web (similarly Internet) is the domain of the average Microsoft user, and therefore must have come from Microsoft, is one that must resonate well with their user base. So when the author says "I even installed a web browser." He is masterfully drawing upon this unspoken belief -- as one of them.
The basic premises of the article are what I would call the "Party Line" of the MStocracy:
- free software can't win - the Linux community is too disorganized to stay around - they started from 1 guy, but they have the same corporate disadvantages as the rest of the industry - to get their free software you have to pay - you don't get any functionality with Linux - Linux is struggling to emulate Windows - Linux is nearly impossible to install and won't recognize your hardware - the stability of the system isn't important - Linux doesn't really perform any better/faster - you can't run your old DOS/Win3.1 programs on Linux
Any of these points can be the basis for a healthy flame war or otherwise religious debate.
The propaganda techniques the author uses include:
- identifies himself as a member of the reader community (here day-to-day MS users with little known contact with Linux). This is particularly ironic since his initial credibility takes him, by definition, out of that group. - establish apparent objectivity by supporting facets of the system which do not conflict with the "party line" tenets - establish that Linux is associated with a group very different from the reader community - make that different group seem overly complex, strange, non-conformist. The important psychological tactic here is that the demographic of the reader group (due to the way the article is targeted) is exceedingly conformist, and will react adversely towards a non-conformist representation. - focus upon the valued facets of the reader's current beliefs (Word documents are important, printing is important...) and analyze the competitor rigidly within this framework. - make the reader group appear to be the important group, the misunderstood group; further highlighting the difference between "us" and "them" - resting upon the implied conclusions, show that the enemy must necessarily fall since our way must be superior to theirs - allow the reader to believe that since "we" drew these conclusions then the reader shares some of the credit - finally establish a feeling of membership in the knowledgeable group by letting the reader know that there are others (fools) around who will still pursue the Linux phenomenon, but "we" know better
A fairly broad array of effective psychological tools. Well done, Herr Shuman.
well, ok brute force isn't the way to go (though dictionary may still be viable).
if they are allowing 73 characters to be typed (I believe that's what I'm counting in their code) then there are:
73^16*73^4 = 73^20 > 2^124
That means that breaking it by brute force is as for all practical purposes as hard as breaking 128 bit encryption by brute force.
Has anyone tried sucking down all the words off their site to use as a seed for a dictionary search? I bet the answer is there (you may have to concatenate and permute their hacker terms for the login name)....
I took a look around to see if I could find a description of their "encryption" system (on the game page) and was able to determine that it's not RC4, RC5, RC6, blowfish, twofish, IDEA (and it's not any S-box based cipher like DES).
I started taking apart the code and determined that it's really a fairly simple algorithm (so simple that it's not covered in _Applied Cryptography_ as far as I can tell) but complicated enough to be troublesome. The encryption key is generated through a simple one-way hash function which is just a slight modification of a modular random number generator. The actual "decryption" just does repeated swaps and xors of the data based on the key.
Here's how the algorithm works:
1 - get the username and password from the page 2 - generate a key from the username/password pair using an algorithm close to a modular random number generator:
a - start with a "seed" of PI (3.14159265...) b - compute the next value from the generator by multiplying the previous value (or seed) by the current username character, adding the current password character and then taking the result mod 256 to keep the range between 0 & 255. c - increment the current username and password characters. if the password character is past the end then wrap it back to 0 (so it's used four times) d - take the number generated and store it in the next available position in the key array.
3 - now that we have the key we do the "decryption" of the hardcoded strings initialized in "lpd_code_1" and "lpd_code_2" -- evidently there are TWO sets of username password pairs. One decrypts "lpd_code_1" and the other "lpd_code_2". This means that on login.html they ask you the username/password used to verify that you didn't cheat and to see if you should get a blue bag or a yellow one (marketing fsckers).
Anyway, the decryption goes like this: 0 - step through the key and the encoded string one character at a time, backwards (no reason to do this backwards but to be obscure -- or to reverse the encryption method which went forwards...) 1 - swap the current string character with the character named by the current key byte (mod 64 to keep things in bounds) -- or the next one if we would be swapping the byte with itself this piece of swapping code is:
which is just an obfuscated swap of the two characters.
2 - xor the (now swapped) character at the current string position with the character at the current key position.
4 - finally, just check if the decryption computed starts with 'http://'
The encryption algorithm is reversible -- just reverse the order of swaps and xors -- but it isn't symmetric (i.e., the encryption algorithm is different from the decryption algorithm). It doesn't look easily invertible either -- that is it would be hard to find the key which generates the encryption from known plaintext (URL) to known cryptotext. If it is invertible then finding the key would allow focusing on just inverting or bruteforcing the key generation hash algorithm.
Since the algorithm, apart from xoring, doesn't use a uniform permutation method I would go out on a limb a bit and say that there are a number (i.e., a lot) of keys which generate the correct URL. The nature of the password hash makes me think there are even more username/password combo's which generate usable keys, but we're still likely talking about an immense number of username/password combos to check. Also, most of those keys would lie outside the valid character set.
This means a dictionary attack is most likely to be effective unless someone can invert the key generation function (not likely).
Of course cracking the server is easier. (I don't at all recommend going to their store as they suggest -- where's the glory in that?)
disclaimer: this is analysis by a complete armchair hack and would be blown away under any consideration by the real crypto folk with any number of serious techniques.
Yes it should... This looks suspiciously like either RC4 or RC5 to me. Maybe even blowfish. I've read the source for the latter 2 (don't think I've seen RC4) and the presence of PI and the xor-swapping looks like a known fast symmetric cipher system, probably one of the 3 (i'll hit dejanews in the sci.crypt archives to figure out which...).
There might be a known-plaintext attack if we can establish which algorithm is being used.. If so brute force would be way too much work.
I submitted a patch for this last night and it's available in the 0.2.0 version on the website. You can also now use '-l' to get the url line without launching the browser (going to be necessary for interfacing with scripting tools or existing apps).
Those of you who are whining so much about spam expose the fact that you couldn't program your way out of an autoexec.bat. A real programmer has written his (her) own spam filter which kills by address and by content -- just for kicks.
For you AC script kiddies on AOL I have no sympathy. Don't expect to restrict our first amendment rights (you don't think any such legislation is narrow and with out subversive amendments do you? I have some wonderful designs for perpetual motion machines for sale which you might be interested in...) because you are too klewless to deal with the effects of your own "Me too!" usenet posts.
Abandon libc5. I just upgraded from RH5.1. After postponing various upgrades ("I'll enable sound later, CD-R doesn't work, etc.") I got around to them last night and said to hell with it and upgraded the kernel too. Hell of a lot sweeter running 2.2.1 than 2.0.34! The goto 2.2 article was all I needed (that and no fear of hosing my modules and accidentally obliterating my old kernel due to sleep deprivation).
Slashdot Mirror
Well, aesthetic reasons aside (because the thought
of running NT under linux is aesthetically
unappealing...), I am inclined to say "because
you can".
This from a guy who saw vmware and immediately
wanted to know if you can run a vmware inside
a vmware (and how deeply they can be nested)...
why? because you can!
Back when I worked in a Solaris shop I would
go hunting for an easy-to-install distribution
of a common utility (pick your favorite) and
would see hundreds of lines in my search that
all contained "linux" in them somewhere, which
invariably meant a (to get them going on Solaris)
a recompile, a failure, a tweak of headers and
makefiles, a recompile, a less-than-perfect
install, etc.
Sun wants to leverage that same code base for
Solaris users (potentially to stop future user-
base drain to Linux). The first step (the easy
one) is to do it for the x86 platform where no
machine code translation has to be done. Now,
the next step is to make it work on the Ultras.
Then you get all the big-$$$ benefits of Solaris
boxen, with the no-$$$ benefits of open source
code ready to run on Linux boxen. Sounds like
a no-brainer to me.
No more difficult than running the arcade version
of Tron on an x86 running Xwindows...
I can compress a whole cd to a 100k file with no loss
Wanna bet? Let me create 650Mb's of prime numbers and see if you can get it down to 100k with no loss. You may be able to compress "a cd" down to that small, but you can't compress any cd down to that size. If you can then for what should be obvious reasons your brain is worth far too much to risk posting silly comments on slashdot (in case The Man is reading).
I stand corrected... forgive my mistake. Back
in '96 (don't laugh) I kept very good tabs on
what was going on with Intel and its competitors
regarding chip technology, with help from friends
placed well at Intel (who would surely like to
remain anonymous). At the time Merced was
described as "essentially RISC" when compared
with the CISC systems then being put out (and
still being put out) by Intel. Over the past
years I kept less abreast of the impending
technologies (having moved my focus to more
software development, and much of that *not* on
Intel systems), but at least kept aware of
scheduled *releases* and some of the current Intel
technology. I clearly missed the IA64 move
(talk about head in the sand) on which I have
justed started to catch up, and hence the "RISC"
discussion above.
The basis of my argument still stands, but the
compilers will be harder to write, and I see now
why there are some delays. Micro$oft does claim
to have a 64-bit windows running on a Merced
simulator (like that isn't a bald-faced lie,
judging by other orthogonal press releases coming
out of Redmond). I still firmly contend that
the current marketing infrastructure for Intel's
products will change if it cannot handle the
responbilities of making money in Intel's Brave
New World. etc., etc., etc.
Thanks for the heads-up.
Roundeye
I'm not sure why this review was written.
Intel has been plagued for a decade by backwards
compatibility with a poorly designed CISC chip
with one of the poorest memory subsystem designs
still in current use. The amount of juice which
can be squeezed from the '86 lemon is limited and
it is a testament to Intel's determination (some
would say stubbornness or stupidity) that they
have been able to make this architecture a
profitable industry standard (of course the more
cynical (myself included on the occasional lonely
night) might chalk this up as a testament to the
power of a tightly run monopoly).
Merced is a necessity if Intel wants to stay
profitable in the face of not only Moore's Law
but AMD and other not-so-dark horses. This chip
has been designed for the most part for years.
The compilers have been under development for
years as well -- anyone who thinks otherwise
doesn't know how Intel does business.
A company which has the resources to write
compilers for superscalar CISC with pipelining,
data forwarding, bizarre MMX
registers/instructions, virtual '86s while
maintaining backwards compatibility with the
original broken design will find writing a new
compiler for a freshly designed clean RISC
system a wonderful relief. The amount of
openly available published research in the RISC
compiler community is significant, and Intel has
the bucks to hire more gurus on the topic if they
need them.
Marketing... It pains me to see so many people
assume that "they way it is" is "the only way
it can work". This is the same fallacious
thinking that makes it painful to watch any
Hollywood movie about time travel or the contact
of our civilization with another (I think
Indpendence Day may be the flagship example of
this) -- the way we Americans do things in this
day and age is superior to the way any other
conceivable society could do them. Cultural
ignorance and arrogance.
This sort of thinking comes up quite often in
discussions of why "Windows will be here forever"
and now appears here in a discussion of Intel's
marketing plan for Merced. The truth of the
matter is that (1) Intel wants the market to
change -- they have been burdened with the '86
albatross for far too long, and (2) the market
will change. Initially we hardware power users,
systems hackers, and speed/systems freaks will
jump on Merced because it is a better chip than
a crappy CISC chip on steroids. The chipsets
to run the chips will be there, and at least
some variation in motherboard configurations.
Dell/Compaq/Gateway will be able to sell a
Merced system.
If, as Intel puts more of its weight behind Merced
(and more applications are brought to Merced) the
current distribution system cannot change their
marketing model to take advantage of the new
configurations which will be possible and then
*desired*, then someone will step up to make the
new money by providing them. Because it's done
a certain way now doesn't mean that that is the
only way (I reiterate at the risk of sounding
pedantic). This industry moves too fast to coddle
companies which have become too large to steer
effectively.
The distribution channels for these systems, and
multi-processor systems, will develop and may
not include the current Big Players in the market.
In addition, as Intel hopes, if AMD et al cannot
create a chip to compete with Merced, and cannot
anchor the market on the '86-type chips, they
may also find themselves too big to steer out
of the way of the Intel truck.
Be careful. Merced could be a swan song for
Intel, but I think it is more likely their
Excalibur.
I agree with your underlying premise that user education is one of the main problems in this type of situation.
n /script_fu/etc. in the powerful applications in current wide use. You make the fallacious unspoken assumption that bloated applications (similar to word/excel/wordperfect/photoshop/access/VB/etc.) are a necessity to the success of Linux. To state it more plainly you assume that for Linux to be successful it must be just like Microsoft is now (in which case why choose one over the other) -- literally that Windows is the only viable solution for computing. To that I say, why should a descendant of the systems from which MS products are so blatantly derivative attempt to close the circle and mimic the poor imitation?
Implying that VBA is a panacea, and that one day Linux is going to require a VBA-clone (at least as regards functionality) is patent bullshit. The functionality is present already in java/CORBA/Gtk/Tk/Perl/C++/OpenGL/Motif/Tcl/pytho
The functionality in *nix (Linux included) as regards interoperability and in-application programmability has historically so far exceeded (for nearly a decade) the laughable attempts MS has made in this area that your supporting argument is ludicrous.
The unfortunate downside is that, as bloatware vendors migrate their products to Linux to attract the $'s of the clueless masses they will invariably take the easy course: using the same broken solutions that sold on a faulty mass-produced system instead of attempting to re-innovate to achieve the "right" solution.
The warning is legitimate but should read: VBA is another "broken whore" (as a lead QA tester for a major networking company once described WinNT to me), and any further UserFriendly scripting solution on *nix should be developed with attention to correctness (security) than attention to bottom-line.
The beauty of the OpenSource paradigm is that a scripting solution (if the community has the need for yet another) will be developed which addresses these issues.
roundeye
For the marketing representatives of Sony reading
this list I am officially making a proposal for
experimentation with this groundbreaking AI
technology and will require eleven (11) Sony(tm)
Dogs(tm) in order to conduct the following
important experiments:
10 - "Identity Crisis" - one week of acclimation
training to dog's given name "Rambo" with
establishment of "his territory", "his chores",
and "his spiked collar". After week one dog
will be referred to by the name "Prissy", shown
"her pink bow", and reprimanded on "violations of
Rambo's territory." "Rambo is a good dog. Prissy
is a bad dog." Prissy will have no "territory".
Rambo's emminent angry return will be prophecied
more and more frequently.
9 - "Navigation" - Dog will be told that my
apartment is "it's wonderful home." Dog will
be taken to the sidewalk and will be told to
"come home!". On the next day dog will be taken
to the end of the block and told to "come home!".
On the third day Dog will be taken to the edge
of the neighborhood and be told to "come home!".
On the fourth day Dog will be placed in the
luggage hold of a Greyhound bus bound for El Paso,
TX and told to "come home!"
8 - "New Dog, New Trick!" - Dog will be taught
to fetch Heineken from refrigerator, being
rewarded after each fetch. After one week, Dog's
legs will be removed and replaced with standard
grocery shopping cart wheels, floor will be waxed
and Dog will be told to "fetch beer". Pictures
of Dog from experiment #9 being placed under bus
with "El Paso, TX" on destination placard will
be shown for motivation.
7 - "Schizoid" - Dog will be trained to go to
front door upon utterance of phrase "go to front
door", and trained to go to back door upon
utterance of phrase "go to back door". Dog's
vocal recorder will be programmed to play sound
clip of experimenter saying "go to back door" when
dog arrives at front door. Dog's vocal recorder
will be programmed to play sound clip of
experimenter saying "go to front door" when dog
arrives at back door. Experimenter utters command
"go to front door."
6 - "Da pimp" - Dog will be shown selections from
an extensive catalogue of bestiality films. Dog
will be dressed in lingerie and placed on a
street corner in a depressed local neighborhood.
Dog will be instructed that "Pimp daddy betta
get all his cash or you ain't nobody's bitch no
more!"
5 - "Doggy Style" - Dog will be shown old Lassie
reruns where Lassie swims to save Timmy. Dog will
be transported via pontoon boat with mannequin
labelled "Timmy" to middle of sizeable community
reservoir. Timmy will be thrown overboard.
Dog will be thrown overboard. Pontoon boat will
return to shore to record observations.
4 - "Silicon brain, Iron Will" - Dog's mobility
circuits will be disabled. Dog will be placed
in front of a television, in an otherwise
empty room, which will play a continuous tape-loop
of "Young Einstein" starring Yahoo Serious.
Dog will be wired to the charging system to
provide continuous recharging.
At the end of one month the Dog will remain
locked in this room with mobility circuits
re-activated.
3 - "Nuremberg" - Dog will be placed on trial
for "crimes against humanity" and sentenced
to execution by Monster Truck. A lengthy but
fruitless appeals process will be conducted
with experimenter playing the roles of public
defender and presiding judge. Dog will be
executed after dramatic "Dead Dog Walking"
march to driveway.
2 - "Franken-tug" - Two Dog's will be trained
to "fetch". Both Dog's will be disassembled
and their front halves joined back to back.
"Dog" will be reactivated and told to "fetch".
1 - "MSCSE" - Dog will be trained to pass the
Microsoft Certified Software Engineer Exam. After
receiving certification, Dog will apply to
Redmond, WA headquarters as a "Lead Developer".
Salary and unavoidable performance bonuses will be
contributed to the Free Software Foundation.
ABC news reported this morning on their radio coverage (as lately as 10pm EST) that the FBI had traced the emergence of the virus to somewhere in Europe, with no mention of AOL, unique IDs, etc.
;)
I would say that ZD and ABC are reporting different information. Is the FBI throwing nonsense to ABC? Does the FBI know about the AOL trace (one would think so)?
Well, whatever. My linux boxen somehow don't appear in the "Address Books" of MS-only users, so I guess that's a blessing. I'd hate to have to read the virus document safely and just delete it
roundeye
The lady's install article was almost fair, and
an echo of things heard in the highly flamed
Katz install dilemma (I think she faired much
more admirably than Katz actually).
The "techie" article was, IMHO, one of the more
disturbing pieces of propaganda that I have seen
as of late. It reminds me of "Purple Heart" -
a WWII-era propaganda movie (one of *ours* folks)
aimed at the Japanese culture and war machine.
By the second paragraph he is already setting out
to portray Linux as confusing, different, and
something that Windows people don't have any
contact with. It appears to me that he is
targeting the average Windows user who has no
contact with Linux (to their knowledge) and
who wants their questions settled in an article
from someplace safe. He makes Linux immediately
seem confusing and alien. Good strategy. Many
of his finer facts are wrong, but within the
realm of plausible deniability. He sets out
immediately the "good guy/bad guy" duality
(Linux is made by one guy instead of a faceless
monolith, but really it's made by a bunch of
faceless organizations who can't decide on
names. Shreds of truth on both counts, but
the second one is where he puts his emphasis)
he uses throughout the rest of the article
to establish "objectivity" while he trashes the
system.
He continues on to draw upon the party line to
subtly attack the FSF's motives. Far be it from
me to side with a Microsoft instrument, but I
have to agree that I don't expect to see sellable
software vanish from the world in my lifetime,
but I don't think that's the point. I'll let
the debaters rage on that one -- I just enjoy
having a choice, being able to use good software
that I can muck around in with the code.
His description of Linux as merely a kernel to
which one could add a windowing system, etc. Is
the first point where I began to get disturbed
and decided to post a response. The author
slips from debatable propaganda/FUD and slight
confusion of facts into a not-so-subtle attack
on the (debatable) weaknesses of Linux with the
implication of "...and so the thing's useless. Go
now back to your homes and play with your Windows
boxes and enjoy your hair." You are free to go
now. The verdict is in.
Linux *is* short of application software when
compared to the Windows software base. To split
hairs one can install Linux without X, but if a
GUI is important to you then you would install
it. The implication that significant extra work
or (as with NT for example) extra purchases must
be performed to install the OS with what should
be considered "standard" features is another
example of fine propaganda techniques. The
implication that the web (similarly Internet) is
the domain of the average Microsoft user, and
therefore must have come from Microsoft, is one
that must resonate well with their user base.
So when the author says "I even installed a web
browser." He is masterfully drawing upon this
unspoken belief -- as one of them.
The basic premises of the article are what I would
call the "Party Line" of the MStocracy:
- free software can't win
- the Linux community is too disorganized to
stay around
- they started from 1 guy, but they have the
same corporate disadvantages as the rest of
the industry
- to get their free software you have to pay
- you don't get any functionality with Linux
- Linux is struggling to emulate Windows
- Linux is nearly impossible to install and won't
recognize your hardware
- the stability of the system isn't important
- Linux doesn't really perform any better/faster
- you can't run your old DOS/Win3.1 programs on
Linux
Any of these points can be the basis for a healthy
flame war or otherwise religious debate.
The propaganda techniques the author uses include:
- identifies himself as a member of the reader
community (here day-to-day MS users with little
known contact with Linux). This is
particularly ironic since his initial
credibility takes him, by definition, out of
that group.
- establish apparent objectivity by supporting
facets of the system which do not conflict with
the "party line" tenets
- establish that Linux is associated with a group
very different from the reader community
- make that different group seem overly complex,
strange, non-conformist. The important
psychological tactic here is that the
demographic of the reader group (due to the
way the article is targeted) is exceedingly
conformist, and will react adversely towards
a non-conformist representation.
- focus upon the valued facets of the reader's
current beliefs (Word documents are important,
printing is important...) and analyze the
competitor rigidly within this framework.
- make the reader group appear to be the
important group, the misunderstood group;
further highlighting the difference between
"us" and "them"
- resting upon the implied conclusions, show that
the enemy must necessarily fall since our way
must be superior to theirs
- allow the reader to believe that since "we"
drew these conclusions then the reader shares
some of the credit
- finally establish a feeling of membership in
the knowledgeable group by letting the reader
know that there are others (fools) around who
will still pursue the Linux phenomenon, but
"we" know better
A fairly broad array of effective psychological
tools. Well done, Herr Shuman.
roundeye
it's not even as complex as IDEA
really just a kind of permutation with
an xoring of the key. the key is generated
as a hash based on pi and the username/password
well, ok brute force isn't the way to go (though
dictionary may still be viable).
if they are allowing 73 characters to be typed
(I believe that's what I'm counting in their
code) then there are:
73^16*73^4 = 73^20 > 2^124
That means that breaking it by brute force is
as for all practical purposes as hard as breaking
128 bit encryption by brute force.
Has anyone tried sucking down all the words off
their site to use as a seed for a dictionary
search? I bet the answer is there (you may
have to concatenate and permute their hacker
terms for the login name)....
I took a look around to see if I could find a
description of their "encryption" system (on the
game page) and was able to determine that it's
not RC4, RC5, RC6, blowfish, twofish, IDEA (and
it's not any S-box based cipher like DES).
I started taking apart the code and determined
that it's really a fairly simple algorithm (so
simple that it's not covered in _Applied
Cryptography_ as far as I can tell) but
complicated enough to be troublesome. The
encryption key is generated through a simple
one-way hash function which is just a slight
modification of a modular random number
generator. The actual "decryption" just does
repeated swaps and xors of the data based on
the key.
Here's how the algorithm works:
1 - get the username and password from the page
2 - generate a key from the username/password
pair using an algorithm close to a modular
random number generator:
a - start with a "seed" of PI (3.14159265...)
b - compute the next value from the generator
by multiplying the previous value (or seed)
by the current username character, adding the
current password character and then taking the
result mod 256 to keep the range between 0 &
255.
c - increment the current username and password
characters. if the password character is past
the end then wrap it back to 0 (so it's used
four times)
d - take the number generated and store it in
the next available position in the key array.
3 - now that we have the key we do the "decryption" of the hardcoded strings initialized
in "lpd_code_1" and "lpd_code_2" -- evidently
there are TWO sets of username password pairs.
One decrypts "lpd_code_1" and the other "lpd_code_2". This means that on login.html
they ask you the username/password used to verify
that you didn't cheat and to see if you should
get a blue bag or a yellow one (marketing fsckers).
Anyway, the decryption goes like this:
0 - step through the key and the encoded string
one character at a time, backwards (no reason
to do this backwards but to be obscure -- or
to reverse the encryption method which went
forwards...)
1 - swap the current string character with the
character named by the current key byte (mod
64 to keep things in bounds) -- or the next
one if we would be swapping the byte with itself
this piece of swapping code is:
lpd_code_1[index] = lpd_code_1[index] ^
lpd_code_1[swap_index];
lpd_code_1[swap_index] = lpd_code_1[index] ^ lpd_code_1[swap_index];
lpd_code_1[index] = lpd_code_1[swap_index] ^ lpd_code_1[index];
lpd_code_2[index] = lpd_code_2[index] ^ lpd_code_2[swap_index];
lpd_code_2[swap_index] = lpd_code_2[index] ^ lpd_code_2[swap_index];
lpd_code_2[index] = lpd_code_2[swap_index] ^ lpd_code_2[index];
which is just an obfuscated swap of the two
characters.
2 - xor the (now swapped) character at the
current string position with the character
at the current key position.
4 - finally, just check if the decryption computed
starts with 'http://'
The encryption algorithm is reversible -- just
reverse the order of swaps and xors -- but it
isn't symmetric (i.e., the encryption algorithm
is different from the decryption algorithm).
It doesn't look easily invertible either --
that is it would be hard to find the key which
generates the encryption from known plaintext
(URL) to known cryptotext. If it is invertible
then finding the key would allow focusing on
just inverting or bruteforcing the key generation
hash algorithm.
Since the algorithm, apart from xoring, doesn't
use a uniform permutation method I would go out
on a limb a bit and say that there are a number
(i.e., a lot) of keys which generate the correct
URL. The nature of the password hash makes me
think there are even more username/password
combo's which generate usable keys, but we're
still likely talking about an immense number of
username/password combos to check. Also, most
of those keys would lie outside the valid
character set.
This means a dictionary attack is most likely
to be effective unless someone can invert
the key generation function (not likely).
Of course cracking the server is easier.
(I don't at all recommend going to their
store as they suggest -- where's the glory
in that?)
disclaimer: this is analysis by a complete
armchair hack and would be blown away under
any consideration by the real crypto folk
with any number of serious techniques.
hope this helps...
Yes it should...
This looks suspiciously like either RC4 or RC5
to me. Maybe even blowfish. I've read the source
for the latter 2 (don't think I've seen RC4) and
the presence of PI and the xor-swapping looks
like a known fast symmetric cipher system,
probably one of the 3 (i'll hit dejanews in the
sci.crypt archives to figure out which...).
There might be a known-plaintext attack if we can
establish which algorithm is being used.. If so
brute force would be way too much work.
l8r
roundeye
I submitted a patch for this last night and it's
available in the 0.2.0 version on the website.
You can also now use '-l' to get the url line
without launching the browser (going to be
necessary for interfacing with scripting tools
or existing apps).
Those of you who are whining so much about spam expose the fact that you couldn't program your way out of an autoexec.bat. A real programmer has written his (her) own spam filter which kills by address and by content -- just for kicks.
For you AC script kiddies on AOL I have no sympathy. Don't expect to restrict our first
amendment rights (you don't think any such legislation is narrow and with out subversive amendments do you? I have some wonderful designs for perpetual motion machines for sale which you might be interested in...) because you are too klewless to deal with the effects of your own "Me too!" usenet posts.
Give us a break!
Abandon libc5. I just upgraded from RH5.1. After
postponing various upgrades ("I'll enable sound later, CD-R doesn't work, etc.") I got around to
them last night and said to hell with it and upgraded the kernel too. Hell of a lot sweeter
running 2.2.1 than 2.0.34! The goto 2.2 article was all
I needed (that and no fear of hosing my modules
and accidentally obliterating my old kernel due
to sleep deprivation).