* Church of Latter-Day Saints sells Joseph Smith-emblazoned coffee mugs in its gift shop.
Ok. I'm dense. What does this mean?
Roughly speaking, Joseph Smith is the founding prophet of the Church of Latter-Day Saints, better known as Mormons. Mormons are forbidden from drinking coffee.
I think that was the gag, but I'm a bit unsure. But the rest of mabu's post was funny.
At one point, I was short on rent and was taking jobs through a major temp agency, one who mostly does secretarial work.
Being a lifelong programmer, I could score 98 WPM on their typing tests. So the next day, I get a call: they need a typist.
One company had bought out another in a hostile takeover, and they needed to transfer the data-- by hand. From printouts, through keyboards. It took five of us a week of solid typing (my wrists were shot at the end of it).
Since I'd gotten pretty good at reverse-engineering file formats, I offered to analyze the old disks and have a computer do the conversion. The manager apparently didn't believe I could do it, and nixed the idea (much to the dismay of the other typists).
You have to pay someone to make a distribution for you,
Only if you want to have a custom distro. Otherwise, you can slap Debian on there.
But seeing as how the Java Desktop System normally costs $100/yr, I'd imagine that Wal-Mart is paying Sun something. And a decent Linux hacker can roll a simple distro fairly quick 'n' cheap, by basing it off of another distro.
Your use of the term "(non)-prototype object" is a bit confusing since every object is a "prototype" which can be cloned... but I think I understand your question.
Yeah, I was being a bit sloppy. I'd imagine that there would be a tendancy (created by programmers, not the language itself) to have objects that are created with the intent of being cloned and not used directly, and objects that are created with the intent of being not cloned; these would roughly correspond to "class" and "instance" in other OOP systems. (Of course, in the more advancecd OOP systems, the distinction between the two can get blurred at times anyway... witness CLOS's MOP.)
Anyway, I'm not sure what the terminology is, but I'd figured you'd catch my meaning.
Inheritance-style call (message) dispatch is handled through a slot named "parent" that every Object has.
Ah! I see. This would also allow you to deal with multiple inheritance in a straightforward way (essentially, make "parent" a list), and multiple dispatch amounts to the same thing that it does in any generic function system.
The article says they're merging Morphic and CLIM... two of the coolest UIs I've ever used. If they pull that off, the UI at least will have definate win potential.
Being a Lisp programmer, I'm always looking for new ideas to bring into my Lisp programs. It looks like Lisp-- possibly even CLOS-- could support prototype-based programming without extensive pain.
One thing that I'm wondering about in prototype-based OOP is redefining stuff. In Smalltalk and CLOS (I don't know Self), you can redefine methods over classes on the fly, or change member variable definitions, or whatever. I take advantage of this to have a production server running for months while I make improvements.
But in a prototype language, this looks, well, difficult. If your methods are associated with prototype objects, then if you have existing non-prototype objects and change a method, then would the non-prototype objects get the method def passed down, or what?
It seems like a prototype language would also have problems with multiple inheritance and multiple dispatch, but it looks like they've licked those too. Interesting.
At one point in my career, I came across this situation to an absurd degree.
One program lets a user select a list of machines. These may either be selected by listing the machines you need ("foo:bar:baz"), or by listing the machines you don't need with a ! ("!quux"). Since the program had a list of all machines, these were equivalent.
I got a customer request to handle "foo:bar:!baz". Cutting through any management, I asked the customer directly what this should mean. I mean, clearly foo and bar are allowed, and baz isn't, but what about quux? What was the intent here?
The customer hesitated, and promptly withdrew the request. He had no semantics in mind; he just wanted the syntax.
The first, in '75, was the Report on the Algorithmic Language Scheme. Then the Revised Report on Scheme. Then RRRS, the Revised Revised Report..., and so on. We're now on the Revised^5 Report on the Algorithmic Language Scheme, usually written R5RS.
But if the encoder throws out phase information, then surround gets thrown out too. I could see this happening in a FFT-based codec.
FM radio is the same way, it wasn't always stereo.
Yes, but to rebroadcast a stereo FM signal, you have to be stereo-aware. The idea behind Dolby PL is that copying equipment didn't need to be PL-aware. But back then, all the duplicating equipment would preserve phase. These days, it may get chunked, inverted, or have other icky stuff happen.
Similar to PL, but the side channels independently are checked for their phase difference from the center channel, rather than from one another, IIRC. It's been a while since I looked at it, tho; you may want to STFW.
X11 was X11 right from the start as far as I remember. The 11 stands for one megapixel (as in a display 1000x1000) and one MIP (million instructions per second).
Sorry, the 11 is a version. From "man X":
The X Consortium requests that the following names be used when referring to this software:
X
X Window System
X Version 11
X Window System, Version 11
X11
I'm guessing your megapixel*MIPS was a retcon. Some of us are actually old enough to barely remember when X10 was just passing out of relevance, and I'd imagine a few of us remember before that. Versions before X10 were never really relevant outside of MIT. X10 was 1986, X11 was 1987, and there's been various X11R*s since then. Today, we use X11R6.4, but many programs want lots of extensions on top of it (eg, XRender). Since many of these have only been implemented on XFree86, that's now a de-facto standard.
So long as 2 computers are exchanging files their IP addresses must be known to each other.
I think you mean, if they're exchanging files *directly*; indirect transfer gets rid of all that. Proxies, anonymizing mail relays, etc, etc. It'd take about 15 minutes to design a file transfer system in which no computer knows the source of a file (unless it's the source), and no computer knows the destination of a file (unless it's the destination) by using wrapped & relayed commutative encrytion and multicast packets. (I'm not saying it would be a secure implementation, but I feel quite sure it's possible in theory.)
Even direct, unencrypted file transfer can take place over the Internet without knowing the source; just use UDP and spoof the source IP. Couple this with multicasting for the destination to conceal itself, and you're pretty well good to go (but somewhat inefficient on bandwidth).
Fake some IDs, listen to employee conversations at a nearby bar after work, sleep with employees and get them to tell secrets, go through trash, make phone calls, take photos, plant bugs, rob, steal, cheat, lie.....
...mug the IT manager for his SecureID, blackmail the tape monkey for backups, assassinate the night guardsman, sure, whatever.
Less severe? One part of a real attack might involve calling in a bomb threat to get one key employee away from his desk. I suspect that it may be better to simulate that part rather than panic the entire building: have one of the high-ups that you're working with call the employee away from his desk for a half hour. Or something.
Yes, the real world doesn't play by rules. But if testing causes more harm than it would have prevented, then it shouldn't take place.
It seems I was wrong. In image technology, RLL is a compression technique. (See the old MacPaint format; I think that BMPs use the same technique.) When I first saw RLL being used in computers, I thought it was the same critter.
From reading your link, I see that the technique is the same, but with a different application: to provide fewer flux changes per mm. But it does so with a significantly lower limit than RLL in image compression does, which causes it to have a constant number of clocks per encoded bit. (In image RLL, the upper limit is often 255 storage bits, so you get a variable number of stored bits per image bit. In some types of images-- mostly the ones that LZW works well on-- this leads to fewer stored bits per image bit.)
The issue here isn't really encryption, it's trust.
SSL (in terms of how it is useful to someone browsing the web) has two roles. One is to "ensure" that data is securely transmitted between two endpoints. The other is to "ensure" that the endpoint(s) is trustworthy.
Point of order: SSL's second role is not about trust, it's about integrity and authentication.
Integrity means that the data that you see is the data that the sender sent. It has not been modified. For example, if I see that my bank balance is $100, then (if proper integrity checks are taking place) I know that the web server sent the value $100, and that an attacker didn't substitute that value for my actual balance.
Authentication means that the data is from who it says it's from. Nobody else sent that data. If proper authentication checks are in place, then I know that the web page I am seeing was sent by my bank, and not by an attacker.
Most cryptosystems that provide authentication also provide integrity. (The opposite is not true; consider MD5 checksums distributed alongside tarballs.)
These have nothing to do with trust. My bank may be a front for the World Crime League and actually has spent my money on Evil Devices with no intention of letting me have it back. This would mean my bank is untrustworthy.
Sure, since RLL is a compression technology. You just put a hardware compression system between the computer and the drive. Completely different beast here.
Slashdot Mirror
That's great! Mind if I include it in Vigor?
* Church of Latter-Day Saints sells Joseph Smith-emblazoned coffee mugs in its gift shop.
Ok. I'm dense. What does this mean?
Roughly speaking, Joseph Smith is the founding prophet of the Church of Latter-Day Saints, better known as Mormons. Mormons are forbidden from drinking coffee.
I think that was the gag, but I'm a bit unsure. But the rest of mabu's post was funny.
At one point, I was short on rent and was taking jobs through a major temp agency, one who mostly does secretarial work.
Being a lifelong programmer, I could score 98 WPM on their typing tests. So the next day, I get a call: they need a typist.
One company had bought out another in a hostile takeover, and they needed to transfer the data-- by hand. From printouts, through keyboards. It took five of us a week of solid typing (my wrists were shot at the end of it).
Since I'd gotten pretty good at reverse-engineering file formats, I offered to analyze the old disks and have a computer do the conversion. The manager apparently didn't believe I could do it, and nixed the idea (much to the dismay of the other typists).
Yick.
You have to pay someone to make a distribution for you,
Only if you want to have a custom distro. Otherwise, you can slap Debian on there.
But seeing as how the Java Desktop System normally costs $100/yr, I'd imagine that Wal-Mart is paying Sun something. And a decent Linux hacker can roll a simple distro fairly quick 'n' cheap, by basing it off of another distro.
I think more accurately it should be called the 'C' desktop.
Yes, because that wouldn't cause any confusion with an existing product either.
Power button?
Admittedly, I don't work in x86 asm land often, but why do you CMP AL right after you MOV into AX, with no label inbetween?
Your use of the term "(non)-prototype object" is a bit confusing since every object is a "prototype" which can be cloned... but I think I understand your question.
Yeah, I was being a bit sloppy. I'd imagine that there would be a tendancy (created by programmers, not the language itself) to have objects that are created with the intent of being cloned and not used directly, and objects that are created with the intent of being not cloned; these would roughly correspond to "class" and "instance" in other OOP systems. (Of course, in the more advancecd OOP systems, the distinction between the two can get blurred at times anyway... witness CLOS's MOP.)
Anyway, I'm not sure what the terminology is, but I'd figured you'd catch my meaning.
Inheritance-style call (message) dispatch is handled through a slot named "parent" that every Object has.
Ah! I see. This would also allow you to deal with multiple inheritance in a straightforward way (essentially, make "parent" a list), and multiple dispatch amounts to the same thing that it does in any generic function system.
Thanks for the insight!
The article says they're merging Morphic and CLIM... two of the coolest UIs I've ever used. If they pull that off, the UI at least will have definate win potential.
Being a Lisp programmer, I'm always looking for new ideas to bring into my Lisp programs. It looks like Lisp-- possibly even CLOS-- could support prototype-based programming without extensive pain.
One thing that I'm wondering about in prototype-based OOP is redefining stuff. In Smalltalk and CLOS (I don't know Self), you can redefine methods over classes on the fly, or change member variable definitions, or whatever. I take advantage of this to have a production server running for months while I make improvements.
But in a prototype language, this looks, well, difficult. If your methods are associated with prototype objects, then if you have existing non-prototype objects and change a method, then would the non-prototype objects get the method def passed down, or what?
It seems like a prototype language would also have problems with multiple inheritance and multiple dispatch, but it looks like they've licked those too. Interesting.
One program lets a user select a list of machines. These may either be selected by listing the machines you need ("foo:bar:baz"), or by listing the machines you don't need with a ! ("!quux"). Since the program had a list of all machines, these were equivalent.
I got a customer request to handle "foo:bar:!baz". Cutting through any management, I asked the customer directly what this should mean. I mean, clearly foo and bar are allowed, and baz isn't, but what about quux? What was the intent here?
The customer hesitated, and promptly withdrew the request. He had no semantics in mind; he just wanted the syntax.
The first, in '75, was the Report on the Algorithmic Language Scheme. Then the Revised Report on Scheme. Then RRRS, the Revised Revised Report..., and so on. We're now on the Revised^5 Report on the Algorithmic Language Scheme, usually written R5RS.
FM radio is the same way, it wasn't always stereo.
Yes, but to rebroadcast a stereo FM signal, you have to be stereo-aware. The idea behind Dolby PL is that copying equipment didn't need to be PL-aware. But back then, all the duplicating equipment would preserve phase. These days, it may get chunked, inverted, or have other icky stuff happen.
Similar to PL, but the side channels independently are checked for their phase difference from the center channel, rather than from one another, IIRC. It's been a while since I looked at it, tho; you may want to STFW.
X11 was X11 right from the start as far as I remember. The 11 stands for one megapixel (as in a display 1000x1000) and one MIP (million instructions per second).
Sorry, the 11 is a version. From "man X":
I'm guessing your megapixel*MIPS was a retcon. Some of us are actually old enough to barely remember when X10 was just passing out of relevance, and I'd imagine a few of us remember before that. Versions before X10 were never really relevant outside of MIT. X10 was 1986, X11 was 1987, and there's been various X11R*s since then. Today, we use X11R6.4, but many programs want lots of extensions on top of it (eg, XRender). Since many of these have only been implemented on XFree86, that's now a de-facto standard.
So long as 2 computers are exchanging files their IP addresses must be known to each other.
I think you mean, if they're exchanging files *directly*; indirect transfer gets rid of all that. Proxies, anonymizing mail relays, etc, etc. It'd take about 15 minutes to design a file transfer system in which no computer knows the source of a file (unless it's the source), and no computer knows the destination of a file (unless it's the destination) by using wrapped & relayed commutative encrytion and multicast packets. (I'm not saying it would be a secure implementation, but I feel quite sure it's possible in theory.)
Even direct, unencrypted file transfer can take place over the Internet without knowing the source; just use UDP and spoof the source IP. Couple this with multicasting for the destination to conceal itself, and you're pretty well good to go (but somewhat inefficient on bandwidth).
Fake some IDs, listen to employee conversations at a nearby bar after work, sleep with employees and get them to tell secrets, go through trash, make phone calls, take photos, plant bugs, rob, steal, cheat, lie.....
...mug the IT manager for his SecureID, blackmail the tape monkey for backups, assassinate the night guardsman, sure, whatever.
Less severe? One part of a real attack might involve calling in a bomb threat to get one key employee away from his desk. I suspect that it may be better to simulate that part rather than panic the entire building: have one of the high-ups that you're working with call the employee away from his desk for a half hour. Or something.
Yes, the real world doesn't play by rules. But if testing causes more harm than it would have prevented, then it shouldn't take place.
This just isn't my day for knowing stuff, is it? :-)
Thanks for the link.
It seems I was wrong. In image technology, RLL is a compression technique. (See the old MacPaint format; I think that BMPs use the same technique.) When I first saw RLL being used in computers, I thought it was the same critter.
From reading your link, I see that the technique is the same, but with a different application: to provide fewer flux changes per mm. But it does so with a significantly lower limit than RLL in image compression does, which causes it to have a constant number of clocks per encoded bit. (In image RLL, the upper limit is often 255 storage bits, so you get a variable number of stored bits per image bit. In some types of images-- mostly the ones that LZW works well on-- this leads to fewer stored bits per image bit.)
Thanks for the info!
The issue here isn't really encryption, it's trust.
SSL (in terms of how it is useful to someone browsing the web) has two roles. One is to "ensure" that data is securely transmitted between two endpoints. The other is to "ensure" that the endpoint(s) is trustworthy.
Point of order: SSL's second role is not about trust, it's about integrity and authentication.
Integrity means that the data that you see is the data that the sender sent. It has not been modified. For example, if I see that my bank balance is $100, then (if proper integrity checks are taking place) I know that the web server sent the value $100, and that an attacker didn't substitute that value for my actual balance.
Authentication means that the data is from who it says it's from. Nobody else sent that data. If proper authentication checks are in place, then I know that the web page I am seeing was sent by my bank, and not by an attacker.
Most cryptosystems that provide authentication also provide integrity. (The opposite is not true; consider MD5 checksums distributed alongside tarballs.)
These have nothing to do with trust. My bank may be a front for the World Crime League and actually has spent my money on Evil Devices with no intention of letting me have it back. This would mean my bank is untrustworthy.
Sure, since RLL is a compression technology. You just put a hardware compression system between the computer and the drive. Completely different beast here.
Not sure how relevent this is, but Gamestop is actually owned by Barnes and Noble.
I doubt it, since Gamestop, Inc. (GME) is a publicly traded company on the NYSE.
Okay, I'm wrong. They are a publicly traded company, but B&N owns 51%. My apologies.
Not sure how relevent this is, but Gamestop is actually owned by Barnes and Noble.
I doubt it, since Gamestop, Inc. (GME) is a publicly traded company on the NYSE.
I only know this because a friend of mine is a Gamestop employee and gets employee discounts at the Barnes and Noble a few stores down.
So do I, and I work for a router company. We just have an agreement with Barnes & Noble, one which they apparently have with many businesses.
Your friend may work in a franchise that's owned by B&N, tho.
McBride and SCO are more hated than Microsoft, the world's largest software maker
Saruman and Isengard are more hated than Sauron, the world's largest glowing eye...
Where did you get this information? We want more!