That's the most board-room compliant cluster I've ever heard of. I bet you could dress it up in a shirt and tie and put it the corner office on the accounting floor and no one would notice.
Ugh. 1855s... Cisco Infiniband? Excuse me while I retch.
..the codename for the facility we're designing for the *** Secure Border Initiative is called SkyNET. We were told to change it... so we did on documentation but use it everywhere internally and with our vendors. We all have a good laugh.:-D
For the most part the POSIX C API uses NUL terminated strings, pointers to structs, and ints (and opaque types that are actually ints). Oh, and small structs made up of that stuff. Perl's scalar numbers internally are the same size as the system's ints, so that handles that detail. Perl auto-coerces strings to numbers and vice-versa. So it can handle the number and string arguments using built-in API functions that just take whatever perl expression and coerce it down to the appropriate scalar context in the glue code. Functions that wanted structs and pointers to them (say, like gettimeofday, select or localtime) would be handled at function call time -- the memory allocated only lasted as long as it was needed to issue the call and copy the return value into the result array for the caller. You had to actually include perl modules that defined all the constants you would otherwise get from say, stdio.h or sys/types.h since perl didn't know about them (like O_RDWR, SEEK_SET, and all that stuff). Or you could hardcode constants.:-D
Yeah, and you'd read Perl man pages and they'd caution you how the behavior of a lot of those bare functions were OS dependant, subject to the OS's specificities (AIX, Linux, Solaris, VMS and Windows, Oh My!). I.E. Linux's select would modify the time left to wait, while Solaris's didn't specify either way (until they introduced pselect(), which didn't, and changed select() so it always did). Which is why the invented Perl IO and IO::Socket, and they introduced "Perl threads" -- so you could do stuff that was close to bare metal without worrying about niggling platform details.
You need to use strict. Why? By default perl is lexical happy. It does what it can with what it knows. This is mostly in the interest of backwards compatibility and for testing stuff with "perl -ne". (You know what I mean...) I imagine Perl 6 will break tradition and "use strict" by default.
I've seen a lot of both. Really shitty, unreadable Perl that makes your head hurt. Stuff that was only designed to execute from top to bottom like a shell script and it only works in the context of some main file. Won't even run if you use sttrict. And beautiful, expressive object-oriented, properly packaged stuff that lets you plug and test it any which way. Stuff you aren't afraid to instrument, modify, or implement because you just understand the author's intent.
They look almost like two different languages.
Then again, I think this is what happen when you have languages that have a lot of built in functionality blessed with tersity and "reasonable defaults".
You can't write spaghetti code in a more structured language like Java or C that does anything useful without code generation.
Perl makes it possible even without syntax highlighting. It's _too easy_ on the programmer.
*shrugs*
It's like VB... except you had a web GUI with a simple "use CGI". And pervasive regular expressions (which, IMHO, is the thing that makes perl unreadable if you don't learn about the m//x modifier). In 1999. So anytime you go online searching google for a Perl script that does XYZ, you end up on one of those code-sharing sites full of "consultants" idiots and you've got the worst kind of code floating around there. Copy and pasted crap with no structure... just hacked up until it works. And Perl's permissiveness allows it to proliferate.
I just write everything myself, or get it from CPAN. CPAN at least acts as a kind of quality control.
If you want to see how to write or model your code, use CPAN modules as examples. You learn alot.
X.509 requires a CA.
on
PGP & GPG
·
· Score: 4, Informative
Until Microsoft starts bundling their Certificate Services in Vista Home editions as a My-Identity-broker kind of thing, X.509 is useless for most people. X.509 is in Outlook because Outlook is the frontend for Exchange.
GPG/PGP are asymmetric cryptosystems that don't rely on PKI infrastructure, just per-user public/private keypairs. Not enterprise friendly but they can be used to bootstrap a trusted online relationship.
... any app the sends email to add meta-data entries to an on-disk copy of the email, with the auto-extracted keywords (concert, tickets) and add the Sent data or something. WinFS just provides the tools to make something like that possible. And really you can't expect any application except for the one that made the notes in the first place to be able to show you that file, or show you a search query interface that makes sense, unless some kind of standard was enforced on wide-classes of metadata.
FUSE is where it's at. User-space loopback. Forget trying to run databases and such in your kernel-space (and IIRC WinFS didn't do that anyway, it ran a Jet engine in user space to manage the meta-data indexes). People have done CRAZY things with that. For example, GMail FS? And a very interesting project: NOOFS. Basically it lets you present a virtual, network-capable FS using FUSE that is backed by a database (with small files inlined and large files as on-disk blobs). You create virtual folders made of SQL queries, can attach arbitrary metadata and ACLs, etc. Can be MySQL or Postgres backed (and I'm sure you could twiddle the Postgres code to talk to Oracle if that floats your boat).
And in XP if you install a free download. (But IIRC it only works when talking to shares coming from a 2k3 server)
Apparently you don't know anything about WinFS
on
WinFS Gets the Axe
·
· Score: 1
WinFS wasn't supposed to replace your hierarchical filesystem. Instead it was a way to add a metadata-indexed database to the existing NTFS that could accessed through new FS-layer APIs by software that cared to use it (for example, Explorer, or Outlook). It was also going to have some nice.NET integration. So, programs could tag opened files through the interface to add meta-data... and it would be stored in indexed form inside the filesystem.
But you could still open the FS in WindowsXP and it's a normal hierarchical FS. You just couldn't see the metadata (it hides in a reserved file in the MFT).
So I don't understand what the problem was... why couldn't they just increment the version number of the NTFS header and leave the APIs available with an SDK. They didn't have to tie it into the interface, if that's the reason why they didn't ship it.
That @foo and $foo are entirely seperate "slots" in the symbol table as far as Perl is concerned. But under the hood both @foo and $foo are both ARRAY refs, it's just that @foo has special copy-by-value semantics and array-context-when-lvalue-ness and other implicit connotations. And you're right (oops), yeah that first -> is required because then you have this ambiguity:
The fact that you had to do this: $x->{"outer hash of references to hashes"}->{"inner hash of scalars or refs"} Was Perl just being precise The outer '$' sigil indicates you wish to treat the whole expression as a scalar lvalue or rvalue. The first '->' indicates you wish to deference a scalar named 'x'. The first '{...}' indicates you wish to treat (deferenced x) as a hash and use the lookup operator on it. The second '->' indicates you wish to treat the return value of the lookup as a reference, and dereference that. The inner '{...}' is the final hash lookup, which returns the scalar you wanted originally.
Incidentally, whenever you see this notation: @array[$index] Internally perl is really doing: *array->[$index] Because array is just an entry in a symbol table that is a reference (just like how arrays in C are pointers, or in Java are objects references). But the @ notation carries additional connatations: when you use it as an lvalue it performs a shallow copy of the array in the rvalue (unlike a scalar reference assignment which only gives you a new handle to the _same_ array)... and it allows you to indicate when you want array or scalar context for functions or operators.
Anyway, at some point (last decade, *eye roll*) someone (Larry) decided that since Perl can tell what kind of reference something is before dereferencing it, that the syntatic sugar that @ and % operators get should apply everywhere (so [] and {} both deference AND lookup, all the time). So all the ->{}/->[] groups can collapse... just like in other languages.
But Perl can do this safely since it already knows what you're trying to do and won't let you do otherwise (using array lookup on a hash reference, for example).
%hash = ( a => { b => { c => d }} ); if($hash{"a"}{"b"}{"c"} == "d") {
print "Whoops... guess you never ran \"man perllol\"\n"; } ### Similarly, for arrays (which are different and faster than hashes in Perl, unlike PHP) $array[0][1][2] = 3;
The old syntax you might be thinking of was:
$hash{"a"}->{"b"}->{"c"} = "d";
Perl has auto-reference traversal for adjacent {}/[] for some time now. You still might need a single arrow:
$myref->{"bar"}{"baz"}
if myref is a reference and not a strict hash or array like the first two examples. (You often get "real references" thrown from functions that don't want to shallow copy
hashes for no good reason onto the stack, and OO Perl uses them heavily)
Which, of course, were also going to be completely free from failures...
So uh, when was the last time you had a failure of a solid state device that wasn't caused by overheating or static electricity?
And the power saving thing shouldn't surprise anybody. It's the power requirements and thermal profile of the device that limits it's marketability and cost basis. As soon as they could transition from tubes to solid state manufacturers produced devices that consumed just as much power, with much higher levels of integration and functionality.
It appears to me that Google (or a 3rd party organization) needs to start a new "trust" index. Kind of like what Yahoo used to look like, where sites that are known to be useful and are actively updated are maintained in some sort of internal database that is updated by Google staff or a non-profit organization.
This site or internal database should be used to inflate the relevance of documents PR/relevance on the trusted domains. The editorial policies of the site might influence these decision.
There could be two kinds of trusted skew. End-skew and transverse-skew. Sites like Wikipedia might only get an end-skew because it's too easy to subtly modify a page to point to a site of your own (and thus get a PR boost by proxy). Tightly controlled sites like MathWorld, on the other hand, might be granted transverse skew.
It could also be used to blacklist sites (like Digital Point) and skew the PR down when it traverses links from there. I would also give a small negative skew, to say, Digg.
So maybe what I'm getting at is content "trustability" metadata. The lower it is, the less likely Google might consider a document from that domain to be authoritative or relevant. If it is very low, it would assign negative skew to any linked sites as well. The higher it is, the more highly it would score it, and at a certain point it pass this bias on to linked sites.
And it would be nice if Google could determine user content from article content on syndicated sites that allow comments. Links and terms contained therein should be weighted differently.
Voluntarily added classes that googlebot can parse for divs?
This all pre-supposes you can translate the diagram accurately and position it in the 3d world. You'd probably need GPS readings at different points on the building, and on the camera to get decent results.
And you need a light model and surface texture models (or a lot of pictures from different angles).
So this isn't trivial. But it's doable. Such techniques are used in film for scene composition and for texturing 3d representations of real-world objects.
It's not like you can just take a picture of a building and have your 3d modeling tool figure out what it's a picture of and create a new texture artifact, etc. You have special tools and workflows to do this. I doubt they'll be bundled with AutoCAD any time soon.
But there's nothing ground breaking about: 1) take picture of things that you have a model of 2) derive textures for model for arbitrary model viewing
you've always been able to do that. Cities aren't the kind of thing this is target for. You can get building plans and architectural drawings and everything from the city for free. There are algorithms that can easily map pictures to objects if you know ahead of time the shape of the things that "should" be there.
This stuff is for deciding the shape of unknown things, and more importantly, to gain new heuristics for image searches.
With this technology, you could ask for "things that are round, and have a box".
More importantly, you could show the computer one picture of something, and have it attempt to find more pictures of it (from different angles, with different colors, etc.). Like you show it a Volvo C90, and it shows you any and all pictures of Volvo C90s by the shape.
You (and many other people) are trying to design INTERFACES.
Web pages (and CSS) were originally designed for marking up DOCUMENTS.
There needs to be an HTML-like variant for designing interfaces. You know, where you aren't fooling yourself into thinking that the display device is anything but a monitor on a computer. No cell phones, no text web browsers, no printers, MAYBE pdas. You could use AJAX, SVG... get rid of a lot of the beat-around-the-bush tag definitions.
In the interim I seriously advise anyone who wants status bars and toolbars and buttons and screen-edge relative positioned content to consider FLASH. Yes Flash. Flash and actionscript are perfect. And you don't even need anything special in the backend... actionscript can launch GET/POST requests to interface whatever you got, it's just ECMAScript. It's got HTML and XML parses and such, so it's well suited.
Booting from SAN doesn't require a local disk. Instead it requires: 1) An expensive fiber adapter 2) Fiber switch 3) SAN storage equipment... filled with a substantial number of drives, at great cost and power consumption.
Which Windows will turn around and treat like a local disk. Blargh. Let me know when you figure out how to boot Windows off a single read-only LUN or from a LAN.
Slashdot Mirror
That's the most board-room compliant cluster I've ever heard of.
I bet you could dress it up in a shirt and tie and put it the corner office on the accounting floor and no one would notice.
Ugh. 1855s... Cisco Infiniband? Excuse me while I retch.
..the codename for the facility we're designing for the *** Secure Border Initiative is called SkyNET. :-D
We were told to change it... so we did on documentation but use it everywhere internally and with our vendors. We all have a good laugh.
For the most part the POSIX C API uses NUL terminated strings, pointers to structs, and ints (and opaque types that are actually ints). Oh, and small structs made up of that stuff. :-D
Perl's scalar numbers internally are the same size as the system's ints, so that handles that detail.
Perl auto-coerces strings to numbers and vice-versa. So it can handle the number and string arguments using built-in API functions that just take whatever perl expression and coerce it down to the appropriate scalar context in the glue code. Functions that wanted structs and pointers to them (say, like gettimeofday, select or localtime) would be handled at function call time -- the memory allocated only lasted as long as it was needed to issue the call and copy the return value into the result array for the caller.
You had to actually include perl modules that defined all the constants you would otherwise get from say, stdio.h or sys/types.h since perl didn't know about them (like O_RDWR, SEEK_SET, and all that stuff). Or you could hardcode constants.
Yeah, and you'd read Perl man pages and they'd caution you how the behavior of a lot of those bare functions were OS dependant, subject to the OS's specificities (AIX, Linux, Solaris, VMS and Windows, Oh My!). I.E. Linux's select would modify the time left to wait, while Solaris's didn't specify either way (until they introduced pselect(), which didn't, and changed select() so it always did).
Which is why the invented Perl IO and IO::Socket, and they introduced "Perl threads" -- so you could do stuff that was close to bare metal without worrying about niggling platform details.
You need to use strict.
Why?
By default perl is lexical happy. It does what it can with what it knows.
This is mostly in the interest of backwards compatibility and for testing stuff with "perl -ne". (You know what I mean...)
I imagine Perl 6 will break tradition and "use strict" by default.
I've seen a lot of both.
Really shitty, unreadable Perl that makes your head hurt. Stuff that was only designed to execute from top to bottom like a shell script and it only works in the context of some main file. Won't even run if you use sttrict.
And beautiful, expressive object-oriented, properly packaged stuff that lets you plug and test it any which way. Stuff you aren't afraid to instrument, modify, or implement because you just understand the author's intent.
They look almost like two different languages.
Then again, I think this is what happen when you have languages that have a lot of built in functionality blessed with tersity and "reasonable defaults".
You can't write spaghetti code in a more structured language like Java or C that does anything useful without code generation.
Perl makes it possible even without syntax highlighting.
It's _too easy_ on the programmer.
*shrugs*
It's like VB... except you had a web GUI with a simple "use CGI". And pervasive regular expressions (which, IMHO, is the thing that makes perl unreadable if you don't learn about the m//x modifier).
In 1999.
So anytime you go online searching google for a Perl script that does XYZ, you end up on one of those code-sharing sites full of "consultants" idiots and you've got the worst kind of code floating around there. Copy and pasted crap with no structure... just hacked up until it works.
And Perl's permissiveness allows it to proliferate.
I just write everything myself, or get it from CPAN.
CPAN at least acts as a kind of quality control.
If you want to see how to write or model your code, use CPAN modules as examples. You learn alot.
n/t
Until Microsoft starts bundling their Certificate Services in Vista Home editions as a My-Identity-broker kind of thing, X.509 is useless for most people. X.509 is in Outlook because Outlook is the frontend for Exchange.
GPG/PGP are asymmetric cryptosystems that don't rely on PKI infrastructure, just per-user public/private keypairs. Not enterprise friendly but they can be used to bootstrap a trusted online relationship.
http://noofs.org/
... any app the sends email to add meta-data entries to an on-disk copy of the email, with the auto-extracted keywords (concert, tickets) and add the Sent data or something.
WinFS just provides the tools to make something like that possible.
And really you can't expect any application except for the one that made the notes in the first place to be able to show you that file, or show you a search query interface that makes sense, unless some kind of standard was enforced on wide-classes of metadata.
FUSE is where it's at. User-space loopback. Forget trying to run databases and such in your kernel-space (and IIRC WinFS didn't do that anyway, it ran a Jet engine in user space to manage the meta-data indexes).
People have done CRAZY things with that.
For example, GMail FS?
And a very interesting project: NOOFS. Basically it lets you present a virtual, network-capable FS using FUSE that is backed by a database (with small files inlined and large files as on-disk blobs). You create virtual folders made of SQL queries, can attach arbitrary metadata and ACLs, etc. Can be MySQL or Postgres backed (and I'm sure you could twiddle the Postgres code to talk to Oracle if that floats your boat).
And in XP if you install a free download. (But IIRC it only works when talking to shares coming from a 2k3 server)
WinFS wasn't supposed to replace your hierarchical filesystem. .NET integration. So, programs could tag opened files through the interface to add meta-data... and it would be stored in indexed form inside the filesystem.
Instead it was a way to add a metadata-indexed database to the existing NTFS that could accessed through new FS-layer APIs by software that cared to use it (for example, Explorer, or Outlook). It was also going to have some nice
But you could still open the FS in WindowsXP and it's a normal hierarchical FS. You just couldn't see the metadata (it hides in a reserved file in the MFT).
So I don't understand what the problem was... why couldn't they just increment the version number of the NTFS header and leave the APIs available with an SDK.
They didn't have to tie it into the interface, if that's the reason why they didn't ship it.
I don't know... I'm disappointed.
That @foo and $foo are entirely seperate "slots" in the symbol table as far as Perl is concerned.
But under the hood both @foo and $foo are both ARRAY refs, it's just that @foo has special copy-by-value semantics and array-context-when-lvalue-ness and other implicit connotations.
And you're right (oops), yeah that first -> is required because then you have this ambiguity:
my $foo = [1, 2, 3];
my @foo = (4, 5, 6);
print $foo[2]; ### Which foo is this?
The answer being it's always '6', and this:
$foo->[2]
Is always '3'.
The fact that you had to do this:
$x->{"outer hash of references to hashes"}->{"inner hash of scalars or refs"}
Was Perl just being precise
The outer '$' sigil indicates you wish to treat the whole expression as a scalar lvalue or rvalue.
The first '->' indicates you wish to deference a scalar named 'x'.
The first '{...}' indicates you wish to treat (deferenced x) as a hash and use the lookup operator on it.
The second '->' indicates you wish to treat the return value of the lookup as a reference, and dereference that.
The inner '{...}' is the final hash lookup, which returns the scalar you wanted originally.
Incidentally, whenever you see this notation:
@array[$index]
Internally perl is really doing:
*array->[$index]
Because array is just an entry in a symbol table that is a reference (just like how arrays in C are pointers, or in Java are objects references).
But the @ notation carries additional connatations: when you use it as an lvalue it performs a shallow copy of the array in the rvalue (unlike a scalar reference assignment which only gives you a new handle to the _same_ array)... and it allows you to indicate when you want array or scalar context for functions or operators.
Anyway, at some point (last decade, *eye roll*) someone (Larry) decided that since Perl can tell what kind of reference something is before dereferencing it, that the syntatic sugar that @ and % operators get should apply everywhere (so [] and {} both deference AND lookup, all the time). So all the ->{}/->[] groups can collapse... just like in other languages.
But Perl can do this safely since it already knows what you're trying to do and won't let you do otherwise (using array lookup on a hash reference, for example).
The old syntax you might be thinking of was:
Perl has auto-reference traversal for adjacent {}/[] for some time now.
You still might need a single arrow:
if myref is a reference and not a strict hash or array like the first two examples.
(You often get "real references" thrown from functions that don't want to shallow copy
hashes for no good reason onto the stack, and OO Perl uses them heavily)
This is perfect. No need to worry about god-awful-slow page-reflows in long documents (which is a seperate MS Word issue but what can you do).
Which, of course, were also going to be completely free from failures...
So uh, when was the last time you had a failure of a solid state device that wasn't caused by overheating or static electricity?
And the power saving thing shouldn't surprise anybody. It's the power requirements and thermal profile of the device that limits it's marketability and cost basis. As soon as they could transition from tubes to solid state manufacturers produced devices that consumed just as much power, with much higher levels of integration and functionality.
Google isn't going to place a datacenter anywhere unless it can easily get at least an OC-48 from two different backbone providers.
That rules out much of the midwest except for the areas around Chicago and Denver.
It appears to me that Google (or a 3rd party organization) needs to start a new "trust" index.
Kind of like what Yahoo used to look like, where sites that are known to be useful and are actively updated are maintained in some sort of internal database that is updated by Google staff or a non-profit organization.
This site or internal database should be used to inflate the relevance of documents PR/relevance on the trusted domains. The editorial policies of the site might influence these decision.
There could be two kinds of trusted skew. End-skew and transverse-skew.
Sites like Wikipedia might only get an end-skew because it's too easy to subtly modify a page to point to a site of your own (and thus get a PR boost by proxy).
Tightly controlled sites like MathWorld, on the other hand, might be granted transverse skew.
It could also be used to blacklist sites (like Digital Point) and skew the PR down when it traverses links from there. I would also give a small negative skew, to say, Digg.
So maybe what I'm getting at is content "trustability" metadata. The lower it is, the less likely Google might consider a document from that domain to be authoritative or relevant. If it is very low, it would assign negative skew to any linked sites as well. The higher it is, the more highly it would score it, and at a certain point it pass this bias on to linked sites.
And it would be nice if Google could determine user content from article content on syndicated sites that allow comments. Links and terms contained therein should be weighted differently.
Voluntarily added classes that googlebot can parse for divs?
This all pre-supposes you can translate the diagram accurately and position it in the 3d world. You'd probably need GPS readings at different points on the building, and on the camera to get decent results.
And you need a light model and surface texture models (or a lot of pictures from different angles).
So this isn't trivial. But it's doable. Such techniques are used in film for scene composition and for texturing 3d representations of real-world objects.
It's not like you can just take a picture of a building and have your 3d modeling tool figure out what it's a picture of and create a new texture artifact, etc.
You have special tools and workflows to do this. I doubt they'll be bundled with AutoCAD any time soon.
But there's nothing ground breaking about:
1) take picture of things that you have a model of
2) derive textures for model for arbitrary model viewing
you've always been able to do that.
Cities aren't the kind of thing this is target for.
You can get building plans and architectural drawings and everything from the city for free. There are algorithms that can easily map pictures to objects if you know ahead of time the shape of the things that "should" be there.
This stuff is for deciding the shape of unknown things, and more importantly, to gain new heuristics for image searches.
With this technology, you could ask for "things that are round, and have a box".
More importantly, you could show the computer one picture of something, and have it attempt to find more pictures of it (from different angles, with different colors, etc.). Like you show it a Volvo C90, and it shows you any and all pictures of Volvo C90s by the shape.
Now there's a title I haven't heard in a long time.
Time to fire up DosEMU. God I loved that game...
You (and many other people) are trying to design INTERFACES.
Web pages (and CSS) were originally designed for marking up DOCUMENTS.
There needs to be an HTML-like variant for designing interfaces. You know, where you aren't fooling yourself into thinking that the display device is anything but a monitor on a computer. No cell phones, no text web browsers, no printers, MAYBE pdas.
You could use AJAX, SVG... get rid of a lot of the beat-around-the-bush tag definitions.
In the interim I seriously advise anyone who wants status bars and toolbars and buttons and screen-edge relative positioned content to consider FLASH.
Yes Flash.
Flash and actionscript are perfect. And you don't even need anything special in the backend... actionscript can launch GET/POST requests to interface whatever you got, it's just ECMAScript. It's got HTML and XML parses and such, so it's well suited.
Booting from SAN doesn't require a local disk.
Instead it requires:
1) An expensive fiber adapter
2) Fiber switch
3) SAN storage equipment... filled with a substantial number of drives, at great cost and power consumption.
Which Windows will turn around and treat like a local disk. Blargh.
Let me know when you figure out how to boot Windows off a single read-only LUN or from a LAN.
It's a really funny site. Do you enjoy trolling the internet?