I work for a DSS/Data mining firm in the retail business. Retailers are not interested in what a consumer wants so that they can charge you more; they want to know what you *don't* want so they don't buy it in the first place. Excess inventory (i.e. wasted money) is the retailers' worst enemy.
They are also not very interested in individual tastes: it's very expensive (technologically) and, as the article points out, the law of diminishing return applies. They really want to know more about seasonal and regional buying patterns, again in an effort to minimize excess inventory.
Keep in mind, if a retailer has excess inventory, they're not likely to just absorb the cost; they will make up for it by marking up the rest of their inventory (they have to make a living after all). So, actually the inverse applies here: if a retailer knows what you (in real-life, their average customer) want, you're gonna end up paying less for it.
Look at the kings of supply-chain optimization: Dell online, Wal-Mart offline (Wal-Mart unbeknownst to many, pioneered data-mining and supply chain management, and they still lead the pack). Neither are known for high-prices or bad customer service, and they have actually achieved fatter profits and higher customer loyalty.
Data Mining is *good* for the consumer, as long as private information is kept private (e.g., names are thrown away, but not data like gender, ZIP codes, or types and frequency of purchases).
engineers never lie; we just approximate the truth.
Did you read my post? I never claimed MySQL can do payroll... I wouldn't trust it with anything of value, much less real money;-)... My point was that Web applications are using DBs as fast data-stores. E.g. for site organization (like/. does with its sections), content management and the like. It's not a big deal if an article is being entered into the DB and the guy who's hitting the site at that very moment doesn't get to see it... It is a big deal though that MySQL will take a much smaller memory and CPU footprint on a small to medium size server than Oracle, or that it will not require a dedicated box (or at least it will take a lot more load before it does).
Further, besides transaction control, there are other issues with an enterprise RDBM: not all data structures are created equal, and an enterprise DB will store things internally in a way that makes sense for ACID --which it's its primary purpose. A read-only (well, read-optimized, but you see what I mean) DB like MySQL can forgo all that and go for a very fast datastorage solution. So, even if you do turn off all control, a very fast enterprise RDBMS will still be handicapped in a performance test with a very fast read-optimized DB. Now, the issue becomes: is MySQL more optimized than Oracle with its years of use and billions of dollars? probably not. But theoretically it could be.
engineers never lie; we just approximate the truth.
MySQL is a light-weight, one-step-up-from-flat-files database, but that doesn't necessarily make it a bad one. Most RDBMSs were built with the enterprise market in mind, for which ACID is a requirement. However, ACID may not be required *at all* when all you need is a fast data store for your web application server:
In a Web environment, speed is (almost always) what matters. To get speed, you have to optimize for the most common operation: e.g. let my inserting this comment into/.'s DB be slow and unreliable (since this comment, despite my best efforts, will never be critical data:-), but OTOH, make sure that the most frequent action (i.e. generating the discussion page with this comment and a few hundred others) is fast as hell. Which it won't be (or, actually, it won't be as fast as it can be) if you are worrying about things like atomicity, rollback, etc, etc...
OTOH, take the article's argument and flip it on its head: a *real* enterprise RDBMS, like Oracle, will *never* be as fast as MySQL for web applications, precisely because it's worrying about transactions and rollback. And, although, I am not a big fan of MySQL, atomicity *can* be rigged on to a non-ACID-able RDBMS from the application end. E.g.: you can keep an array in Java/Perl/PHP that tells the application which DB tables are being written to, so read operations can *choose* to come back and try the read a few cycles later or instead opt to ignore atomicity (which is perfectly good for the web).
engineers never lie; we just approximate the truth.
I own a Gateway Solo (PII 300PE) with the Kingmax DVD PC card you mentioned and a G1 DVD (Matshita). I've had it hooked up to a 40" TV and a 4-speaker Dolby-able stereo. Quality of picture and sound (including high-speed motion) was exceptional (at least equal to component DVD players I've seen). Problems I've had:
Only one movie had motion compensation problems -- "Ronin" during some action sequences. And if you've seen "Ronin" you understand. But this may be related to...
... a short time later, the player started seriously skipping. Since the laptop was under warranty, Gateway fixed it. No problems since.
The really irritating thing about having a laptop as a component is the lack of a remote. Also the fact that if the laptop starts doing anything, for any reason (say fetch e-mail, start a virus scan, etc) the DVD will most likely skip.
OTOH, all this was with a first generation (1x) DVD and 64MB of RAM... I think they're up to 4x DVDs now, so skipping should be much less noticable...
engineers never lie; we just approximate the truth.
Yes, it's reliable enough to fly an aircraft by... a Stanford team demonstrated this with a model aircraft circa 1996. And later, they encored by driving a tractor around...
engineers never lie; we just approximate the truth.
Use the other kind of 'munitions'...
on
Laptop Lojack?
·
· Score: 2
...cryptography. Cheap, easy and truly secure (coz the 'black helicopters' always have bomb experts on board:-)... For the truly paranoid, there are several utilities that will use strong encryption to secure whole disk partitions (and some work flawlessly and transparently with Windows and/or Linux).
...good GUIs put the human first. It's just as simple as that.
Why is that I can find something easier on the Web (thanks Google!) than I can on my hard drive? Why can't I use the same spell-checker (yes, including the same custom dictionary) in my MUA that I use for word processing? Why do I have to dig through directories, hierarchical structures and all that crap to find a file? Because someone, somewhere, was coding an application and stuck to the design that was easier to *implement*, not easier to *use*.
A drive structure should not be exposed to the user; documents must be tracked by the OS, not the user. Functions and functionality should be transparent and consistent in all applications. The Macintosh succeeded in the first points (hide the machine complexity away behind closed doors), Windows succeeded in the last --all Windows apps (make that *Microsoft* Windows apps) share components, functionality, and up to a point design philosophy (yes, I know, that's not 100% true, Word doesn't do everything the same way that Excel does, but they are very, very close).
Gnome and KDE should learn from their predecessors' successes and failures, rather than copying them blindly --and if you're gonna copy antyhing, please not CDE;-)...
engineers never lie; we just approximate the truth.
Linux has more applications: true, but so what? does AOL care? the only applications they would care about is a customizable browser they can deliver their proprietary content too, and they already got one, and multimedia stuff for enhanced-TV and the like (and here's where Be would really shine).
Developers: a) I am willing to bet that internally Be has already a team of people porting Mozilla over; it makes sense, especially given their BeIA strategy. AOL could inherit that effort and augment it with Netscape engineers, b) how important really is number of developers when AOL can afford to double and triple that number if they wanted to?
Linux/Mozilla: Linux is Mozilla's preferred platform, coz Linux is popular and doesnt have a decent browser: ergo, more Linux users are interested in/helping out Mozilla than from any other OS. But if AOL/Netscape's interests switched to another OS, and the number of full-time developers working on Mozilla/Be doubled, that will not matter any more.
Of course, all this is just conjecturing for fun, but it does make sense at some level. It certainly makes as much as sense for AOL as buying Nullsoft or Mirabilis...
engineers never lie; we just approximate the truth.
Isn't it obvious? Be is down financially, AOL has all the components it needs to be Windows free, except an OS. Yeah, they could go with Linux, but AOL has always tried to remain proprietary. Be will give them a foray into internet appliances (think set-top boxes and web-pads), has the multimedia capabilities that AOL craves (think AOLTV) and will tie-in beautifully with Mozilla.
It just makes sense. I am starting this rumor right now;-)...
engineers never lie; we just approximate the truth.
My employer does a lot of data-mining at a very low level: we have one of the most complex read *and* write data-mining applications out there, and yes we do a lot in SPLs, and SQL and C++ and even our own in-house languages. I am confident (in fact, I know) that you can considerably out-perform SQL if you write "to the metal", in this case the data-structure itself.
Knowing this, and the problem I laid out before (that the DB developer doesn't know what the application developer needs) I have personally started to question the need for an RDBMS, particularly in the case of Web applications.
Let's face it, a full RDBMS for a data-store of a few TBs makes perfect sense, but for a website of a few pages (even a few hundred pages) it's overkill, especially, as a lot of posts have said so far, since that's where your bottleneck is in dynamic sites. So why are we running full RDBMS, or even low-powered clones of such (i.e. MySQL)?
I am willing to bet performance would go wayyy up, if you could have a relational data structure directly available from PHP (a basic B* tree, for example). Why?
One factor: PHP does caching; but it can't cache an *external* data source, such as a DB table, because it can't be sure that it was not modified by someone else; but, if the datasource was *internal* to PHP, caching of records, queries or whole tables would be simple: less disk/data access = more speed.
If you are not familiar with the wonders of PHP4 (not 3.x), check out php.net (and the best online manual in existence) and the now private company behind their engine, Zend. The Zend folks have recently got together with the MySQL folks, to further integrate the two platforms; there is a chance they will end up with a direct access scheme --and that's the main reason I am betting on PHP...
engineers never lie; we just approximate the truth.
PHP 4.0 and the latest version of ASP (don't use it don't know the version #) are both compiled to bytecode (very much like Java). JSP is *parsed* by the servlet is been run under, translated to a plain Java file and then compiled to Java bytecode (maybe newer JSP engined compile directly to bytecode, I am not sure, this is the case with JServ 1.1 + GnuJSP).
Now, stored SPL procedures (which is not the same thing as SQL --SQL is the root of most SPL languages, but pretty much each vendor has their own) are also compiled to bytecode and stored within the DB structure.
So far, if we're comparing the two schemes, we've gained nothing in comparison: both language genres compile to some machine-independent bytecode that's supposedly slower than assembly and faster than interpreted languages.
Under this layer is where things get interesting: how does SQL/SPL access the data structure? through a proprietary, vendor specific library. How do PHP/ASP/Java? thru SQL. That's where the performance difference comes in.
What would you rather code in? SQL or PHP? Java or some vendor specific stored procedure language? (which not only locks you in, it probably has less features and is not as robust). What would kick some major ass, would be to circumvent SQL and access the data structures *directly* from PHP/Java. SQL is not the end-all, be-all of data access. It's just entrenched, and the lowest common denominator (you can always figure a way to do anything in SQL).
The other layer you're missing is the data-structure itself: the DB vendor (Oracle in our case) doesn't know what you're gonna end up doing with the DB --thus, they lock you in to certain type of data structure (and no, not all DB data structures are created equal). That's really the reason we now have really fast-read RDBMSs like MySQL that suck for transactions, cool OOP-like ORDBMS like Postgres that suck for reads, and a multitude of commercial DBs that each have their niche.
But the end-developer (the PHP author here) *does* know what each data structure will end up doing. So, if you can have a common API from PHP that can access several types of data structures *directly* (NOT thru SQL), and you could specify what you want (fast read, object-store, transactions), all the advantages of a proprietary RDBMS go away. That's where OSS could kick ass: write the structures and the libraries to read them and use a common, rich language to access them *directly*.
We're not really disagreeing; C++ will always be faster on the server side. But the server side is controllable by the developer/deployer: you can always add more muscle to your servers. Development time, flexibility and robustness are more important.
engineers never lie; we just approximate the truth.
Errr... Stored procedures in DBs are basically compiled to bytecode that has faster access to the DB structure (i.e. probably a C library).
Now, contrast this to a modern scripting language (PHP4, ASP) or Java --a high level language (not unlike a SPL) that also compiles to bytecode. The performance difference here is access to the data structure: in all the languages above (ASP, PHP, Java) the way the DB is accessed (i.e. the speed of the JDBC, ODBC driver or PHP module) is what determines the speed of access to the DB.
In other words, there really isn't much of a difference between using an SPL in a DB or an external scripting language that has fast access to the DB data --e.g. the PHP module for MySQL. I think what confuses you here is that Oracle has *never* given a C library (or anything similar) for access to the DB structure, forcing everybody to use their proprietary SPL.
IMHO, the future lies with highly developed, open and popular languages (PHP and Java being my favorites here) that have C-level access to data structures *directly*. I.e. you could potentially get rid of SQL (or make SQL another language with access to the C library) and, more importantly you could have different types of data structures in the same application: e.g. a very fast read-only DB file (think MySQL) and a robust object-store DB (think Postgres) that look and feel the same to the end developer (the PHP dude). If anybody wants to start an OSS project like that, count me in;-)...
engineers never lie; we just approximate the truth.
GPS is so prevalent in the 'new', 'modern' battlefield that a device like this makes a lot of sense and I am sure that a lot of militaries have already built their own --or if not, they are starting up similar projects as we type...
Just some potential uses of a GPS jammer: Handheld and dashboard-mounted GPS is used all the time in tanks/helicopters/ships and by troops in the field. In most cases (i.e. outside of the US) these are *commercial* grade GPS, not US Military-grade GPS --i.e. they will be much less resistant to jamming.
The US Military, OTOH, has put so much faith into GPS, it's now using it to guide smart bombs and cruise missiles... so, you can see, the fact that the US Air Force itself has proven that it is feasible to jam GPS with COTS (commercial off-the-shelf) technology will be a HUGE deal to the defense planners of the world...
Now, I am not a EE, much less a DSP/GPS specialist, but from my knowledge of the system I am guessing that: a) the system described above won't be much use against fast-moving airborne GPS (fighters), and b) US Military-grade GPS can be affected just as effectively --as I believe that the US Navy is using an encoded higher time-resolution signal to achieve more accurate measurements. But if the signal is jammed, encryption won't be much use, right?
engineers never lie; we just approximate the truth.
Re:GPL requires Copyright law
on
RMS On eBooks
·
· Score: 3
Maybe I am being naive, here, but without copyright enforcement how could a GPL author *enforce* derivative works to be under the GPL?
It seems to me that w/o copyright law, the effective use of any open-source software would allow BSD-like freedoms rather than GPL. I don't want to start the holy war again here; I may just be misunderstanding the GPL. I do think both licenses have their places and their uses...
engineers never lie; we just approximate the truth.
Excellent points; let me add a coupla more: I am not sure what 'real time mathematical computations' means here. CPUs that can crunch complex mathematical systems in real time, are usually developed by DARPA and cost millions per unit (I am referring to jet fighter avionics packages; usually TI or Rockwell chips).
Now, if the poster is referring to mathematical problems (but not 'real time', more like 'solved in a reasonable time'), the above post is right on the money: do not buy an SMP system --at least not an x86 SMP system (I don't have any exprience with Alphas). The problem with x86 SMPs is bus speeds, i.e. communication between CPUs on the same board. Using fast network interconnects (gigabit speeds) you can usually get better performance between boxes than between CPUs for some SMP systems (particularly quads and 8-ways). Duals are not as problematic, so for compactness' sake they might worth the $$$...
Keep in mind though, this is not the way things *should* be, it's just the state of the art --which sucks right now in x86-land. With better motherboards coming up (not to mention better SMP support by all the different OSes --the new Linux kernels seem to have solved context switching problems that were killing SMP machines, for example), eventually SMP machines will be the way to go...
engineers never lie; we just approximate the truth.
One More: the IDChip hoax
on
Hoax-a-go-go!
·
· Score: 2
This is one of the best Web-hoaxes I've found (well, so far;-):
A guy created this fake (and not really real-looking) commercial site selling the "IDChip" which was described (on purpose) a lot like the "sign of the Beast" from Revelation. He got so many e-mails and death-threats from religious fanatics, he had to shut down and reveal the hoax in less than a week. Definitely worths the click to his "letters" section;-)...
engineers never lie; we just approximate the truth.
Privatize NASA? y'all on drugs?;-)... In a sense NASA is *already* privatized: when it spends a few hundred million dollars on an X plane that validates a technology some company (Boeing, Lockheed, Northrop --the only ones left really) will build an aircraft around, the money does eventually flow to the private sector. The single greatest example is perhaps the X-33, where NASA is essentially subsidising the development of a commercial launch vehicle.
But what most of the readers here fail to realize is that NASA *must* stay as a government agency for both scientific and economical reasons: Scientific, becuase as others mentioned, NASA has probably the best 'research ethic' in the world. The people there are more free to pursue their own research interests than they would in a corporate R&D facility or in a (corporate-subsidized) research university.
Most importantly though, NASA cannot *afford* to be private; the financial threshold for entry into the aeronautical or space business would have any Valley VC running scared... most big commercial aerospace projects (a good example is the 777) don't pay themselves off until a *decade* or so into production. Boeing is large enough (and the governments behind Airbus can tax enough) to keep those huge cash reserves around, but the stock market doesn't have that kind of patience, especially this market of 6-months-from-incorporation IPOs...
What is truly sad is that most of this wealth is being created by companies largely immitating one another, while true innovators are punished because they are 'sinking' their profits into R&D (who's 'hotter': VA or IBM? Lucent or ?)
engineers never lie; we just approximate the truth.
While I agree with almost everything you said (including the part about Linux being an excellent imitator and a rare innovator), I am tired of seeing the same premise being used again and again wrt OSS: you don't necessarily need a buncha 'lone hackers' hacking away at a problem.
Let's suppose that a fairly good-sized company came out with an open-sourced RDBMS/OLAP framework, that has all the groundwork to be fast and extensible. I am sure there are a few companies out there that would benefit to contribute to such a project for their own uses... Why can't OSS act as a framework and collaboration scheme, instead of just a toy for hobbyists?
engineers never lie; we just approximate the truth.
Not all DSS environments are/should be read-only. My employer deploys one of the largest (if not the largest) read-write DSS client-server application.
Transactions/Rollback are not critical (we have our own rollback solution over Acumate, made by Kenan) but in a read-write environment, they sure are good to have around.
OTOH, you're right; in a DSS environments reads are always way more common than writes, so a rollback layer could actually be preferrable to a built-in transactional functionality.
So, forget about transactional control, it's not even essential; are there *any* OSS OLAP apps out there? they sure would make a nice toy;-)...
engineers never lie; we just approximate the truth.
I've done some research on this topic, and by far the most open/tested OSS RDBMS out there is PostgresSQL, which is actually based on the same tree from which a commercial RDBMS, Ingres, was spawned. However, I do not believe that Postgres is solid/fast enough for enterprise level applications yet (mind you, this is from reading a lot of Usenet and Web opinions on it, not personal experience, so YMMV).
Since I am a DSS ("Data Mining") guy though, I am more interested in an extension to your question? is there any decent OSS OLAP/DSS DB system out there that can handle multiple dimensions, transactions, partitioning, ? If not, how many people would be interested in one?
engineers never lie; we just approximate the truth.
Huh? Finite differences are still very widely used; most (like 80%+) of CFD is done using finite differences. Actually, in any model that you're examining a finite volume of space, rather than an object, you're most likely using finite differences (i.e. fluid problems, including AFAIK weather simulation).
Finite elements are mainly used for objects/mechanisms, particularly structures analysis (incl. car simulation) and manufacturing (metal stamping).
engineers never lie; we just approximate the truth.
Technologies don't die; they evolve.
on
The End of Unix?
·
· Score: 2
Unix will not 'die'; neither will DOS, or MacOS, or Windows --any technology that it's innovative and gains enough mindshare lives on in other technologies. As long as a philosophy, concept of feature is liked enough, people will re-implement it under different systems... Do you forget that Linux was a Unix re-write?
Sadly, it seems that things aren't evolving as fast as they could. Linux *is* a Unix rewrite, and it's still not that much better than its foundation. NeXTStep re-implemented Unix a decade ago and it did a much better job --so much so, that its successor Mac OS X has still a big technological edge...
I wonder if the Linux community can look ahead far enough to stop worrying about backwards compatibility with older Unices and start innovating in the fundamentals of the OS. Security, administration, configuration, maintenance, documentation and quality of service are hopelessly krufty and kludgy in most Unices and Linux too.
There was a point that Linux needed to emulate its siblings, to remain relevant and useful. But in the next few years it's quite possible that Linux will become the dominant Unix-clone. Compatibility and tail-light chasing be damned --we need to innovate.
engineers never lie; we just approximate the truth.
I am not surprised by the fact that the US intelligence agencies perform industrial espionage. What appals me is the self-congratulating excuse that the US has to do it because European companies are not good enough to win contracts on their own merits, so they have to stoop to bribery.
I am European... I've worked and lived in the US. I've also lived and worked in Europe. I've been close enough to billion-dollar contracts to have an idea what's going on. For anyone to claim that somehow US corporations are the keepers of corporate morality in the international marketplace is ridiculous...
So, does anybody out there remember what the term "Banana Republic" actually meant before it became a clothing store? Does anyone remember what the greatful Saudis did after the end of the Gulf War? Mayhaps they went ahead and bought a buncha F-15s? didn't they also let Boeing have a huge contract of airliners for the state-owned airline?
Now, I ain't saying that somehow American companies are better or worse than British, French or Dutch ones; but to claim that they are indeed so much so more moral as to justify these actions (regardless of the fact that really everybody does it) is absurd.
engineers never lie; we just approximate the truth.
Slashdot Mirror
I work for a DSS/Data mining firm in the retail business. Retailers are not interested in what a consumer wants so that they can charge you more; they want to know what you *don't* want so they don't buy it in the first place. Excess inventory (i.e. wasted money) is the retailers' worst enemy.
They are also not very interested in individual tastes: it's very expensive (technologically) and, as the article points out, the law of diminishing return applies. They really want to know more about seasonal and regional buying patterns, again in an effort to minimize excess inventory.
Keep in mind, if a retailer has excess inventory, they're not likely to just absorb the cost; they will make up for it by marking up the rest of their inventory (they have to make a living after all). So, actually the inverse applies here: if a retailer knows what you (in real-life, their average customer) want, you're gonna end up paying less for it.
Look at the kings of supply-chain optimization: Dell online, Wal-Mart offline (Wal-Mart unbeknownst to many, pioneered data-mining and supply chain management, and they still lead the pack). Neither are known for high-prices or bad customer service, and they have actually achieved fatter profits and higher customer loyalty.
Data Mining is *good* for the consumer, as long as private information is kept private (e.g., names are thrown away, but not data like gender, ZIP codes, or types and frequency of purchases).
engineers never lie; we just approximate the truth.
Did you read my post? I never claimed MySQL can do payroll... I wouldn't trust it with anything of value, much less real money ;-)... My point was that Web applications are using DBs as fast data-stores. E.g. for site organization (like /. does with its sections), content management and the like. It's not a big deal if an article is being entered into the DB and the guy who's hitting the site at that very moment doesn't get to see it... It is a big deal though that MySQL will take a much smaller memory and CPU footprint on a small to medium size server than Oracle, or that it will not require a dedicated box (or at least it will take a lot more load before it does).
Further, besides transaction control, there are other issues with an enterprise RDBM: not all data structures are created equal, and an enterprise DB will store things internally in a way that makes sense for ACID --which it's its primary purpose. A read-only (well, read-optimized, but you see what I mean) DB like MySQL can forgo all that and go for a very fast datastorage solution. So, even if you do turn off all control, a very fast enterprise RDBMS will still be handicapped in a performance test with a very fast read-optimized DB. Now, the issue becomes: is MySQL more optimized than Oracle with its years of use and billions of dollars? probably not. But theoretically it could be.
engineers never lie; we just approximate the truth.
MySQL is a light-weight, one-step-up-from-flat-files database, but that doesn't necessarily make it a bad one. Most RDBMSs were built with the enterprise market in mind, for which ACID is a requirement. However, ACID may not be required *at all* when all you need is a fast data store for your web application server:
/.'s DB be slow and unreliable (since this comment, despite my best efforts, will never be critical data :-), but OTOH, make sure that the most frequent action (i.e. generating the discussion page with this comment and a few hundred others) is fast as hell. Which it won't be (or, actually, it won't be as fast as it can be) if you are worrying about things like atomicity, rollback, etc, etc...
In a Web environment, speed is (almost always) what matters. To get speed, you have to optimize for the most common operation: e.g. let my inserting this comment into
OTOH, take the article's argument and flip it on its head: a *real* enterprise RDBMS, like Oracle, will *never* be as fast as MySQL for web applications, precisely because it's worrying about transactions and rollback. And, although, I am not a big fan of MySQL, atomicity *can* be rigged on to a non-ACID-able RDBMS from the application end. E.g.: you can keep an array in Java/Perl/PHP that tells the application which DB tables are being written to, so read operations can *choose* to come back and try the read a few cycles later or instead opt to ignore atomicity (which is perfectly good for the web).
engineers never lie; we just approximate the truth.
Only one movie had motion compensation problems -- "Ronin" during some action sequences. And if you've seen "Ronin" you understand. But this may be related to...
The really irritating thing about having a laptop as a component is the lack of a remote. Also the fact that if the laptop starts doing anything, for any reason (say fetch e-mail, start a virus scan, etc) the DVD will most likely skip.
... I think they're up to 4x DVDs now, so skipping should be much less noticable...
OTOH, all this was with a first generation (1x) DVD and 64MB of RAM
engineers never lie; we just approximate the truth.
Yes, it's reliable enough to fly an aircraft by... a Stanford team demonstrated this with a model aircraft circa 1996. And later, they encored by driving a tractor around...
engineers never lie; we just approximate the truth.
Some utilities:
Scramdisk (my personal favorite)
BestCrypt
PGP Disk
E4M
And to ease day-to-day operation: SecureTray (Windows tray utility to manage encrypted partitions).
engineers never lie; we just approximate the truth.
...good GUIs put the human first. It's just as simple as that.
;-)...
Why is that I can find something easier on the Web (thanks Google!) than I can on my hard drive? Why can't I use the same spell-checker (yes, including the same custom dictionary) in my MUA that I use for word processing? Why do I have to dig through directories, hierarchical structures and all that crap to find a file? Because someone, somewhere, was coding an application and stuck to the design that was easier to *implement*, not easier to *use*.
A drive structure should not be exposed to the user; documents must be tracked by the OS, not the user. Functions and functionality should be transparent and consistent in all applications. The Macintosh succeeded in the first points (hide the machine complexity away behind closed doors), Windows succeeded in the last --all Windows apps (make that *Microsoft* Windows apps) share components, functionality, and up to a point design philosophy (yes, I know, that's not 100% true, Word doesn't do everything the same way that Excel does, but they are very, very close).
Gnome and KDE should learn from their predecessors' successes and failures, rather than copying them blindly --and if you're gonna copy antyhing, please not CDE
engineers never lie; we just approximate the truth.
Linux has more applications: true, but so what? does AOL care? the only applications they would care about is a customizable browser they can deliver their proprietary content too, and they already got one, and multimedia stuff for enhanced-TV and the like (and here's where Be would really shine).
Developers: a) I am willing to bet that internally Be has already a team of people porting Mozilla over; it makes sense, especially given their BeIA strategy. AOL could inherit that effort and augment it with Netscape engineers, b) how important really is number of developers when AOL can afford to double and triple that number if they wanted to?
Linux/Mozilla: Linux is Mozilla's preferred platform, coz Linux is popular and doesnt have a decent browser: ergo, more Linux users are interested in/helping out Mozilla than from any other OS. But if AOL/Netscape's interests switched to another OS, and the number of full-time developers working on Mozilla/Be doubled, that will not matter any more.
Of course, all this is just conjecturing for fun, but it does make sense at some level. It certainly makes as much as sense for AOL as buying Nullsoft or Mirabilis...
engineers never lie; we just approximate the truth.
Isn't it obvious? Be is down financially, AOL has all the components it needs to be Windows free, except an OS. Yeah, they could go with Linux, but AOL has always tried to remain proprietary. Be will give them a foray into internet appliances (think set-top boxes and web-pads), has the multimedia capabilities that AOL craves (think AOLTV) and will tie-in beautifully with Mozilla.
;-)...
It just makes sense. I am starting this rumor right now
engineers never lie; we just approximate the truth.
My employer does a lot of data-mining at a very low level: we have one of the most complex read *and* write data-mining applications out there, and yes we do a lot in SPLs, and SQL and C++ and even our own in-house languages. I am confident (in fact, I know) that you can considerably out-perform SQL if you write "to the metal", in this case the data-structure itself.
Knowing this, and the problem I laid out before (that the DB developer doesn't know what the application developer needs) I have personally started to question the need for an RDBMS, particularly in the case of Web applications.
Let's face it, a full RDBMS for a data-store of a few TBs makes perfect sense, but for a website of a few pages (even a few hundred pages) it's overkill, especially, as a lot of posts have said so far, since that's where your bottleneck is in dynamic sites. So why are we running full RDBMS, or even low-powered clones of such (i.e. MySQL)?
I am willing to bet performance would go wayyy up, if you could have a relational data structure directly available from PHP (a basic B* tree, for example). Why?
One factor: PHP does caching; but it can't cache an *external* data source, such as a DB table, because it can't be sure that it was not modified by someone else; but, if the datasource was *internal* to PHP, caching of records, queries or whole tables would be simple: less disk/data access = more speed.
If you are not familiar with the wonders of PHP4 (not 3.x), check out php.net (and the best online manual in existence) and the now private company behind their engine, Zend. The Zend folks have recently got together with the MySQL folks, to further integrate the two platforms; there is a chance they will end up with a direct access scheme --and that's the main reason I am betting on PHP...
engineers never lie; we just approximate the truth.
PHP 4.0 and the latest version of ASP (don't use it don't know the version #) are both compiled to bytecode (very much like Java). JSP is *parsed* by the servlet is been run under, translated to a plain Java file and then compiled to Java bytecode (maybe newer JSP engined compile directly to bytecode, I am not sure, this is the case with JServ 1.1 + GnuJSP).
Now, stored SPL procedures (which is not the same thing as SQL --SQL is the root of most SPL languages, but pretty much each vendor has their own) are also compiled to bytecode and stored within the DB structure.
So far, if we're comparing the two schemes, we've gained nothing in comparison: both language genres compile to some machine-independent bytecode that's supposedly slower than assembly and faster than interpreted languages.
Under this layer is where things get interesting: how does SQL/SPL access the data structure? through a proprietary, vendor specific library. How do PHP/ASP/Java? thru SQL. That's where the performance difference comes in.
What would you rather code in? SQL or PHP? Java or some vendor specific stored procedure language? (which not only locks you in, it probably has less features and is not as robust). What would kick some major ass, would be to circumvent SQL and access the data structures *directly* from PHP/Java. SQL is not the end-all, be-all of data access. It's just entrenched, and the lowest common denominator (you can always figure a way to do anything in SQL).
The other layer you're missing is the data-structure itself: the DB vendor (Oracle in our case) doesn't know what you're gonna end up doing with the DB --thus, they lock you in to certain type of data structure (and no, not all DB data structures are created equal). That's really the reason we now have really fast-read RDBMSs like MySQL that suck for transactions, cool OOP-like ORDBMS like Postgres that suck for reads, and a multitude of commercial DBs that each have their niche.
But the end-developer (the PHP author here) *does* know what each data structure will end up doing. So, if you can have a common API from PHP that can access several types of data structures *directly* (NOT thru SQL), and you could specify what you want (fast read, object-store, transactions), all the advantages of a proprietary RDBMS go away. That's where OSS could kick ass: write the structures and the libraries to read them and use a common, rich language to access them *directly*.
We're not really disagreeing; C++ will always be faster on the server side. But the server side is controllable by the developer/deployer: you can always add more muscle to your servers. Development time, flexibility and robustness are more important.
engineers never lie; we just approximate the truth.
Errr... Stored procedures in DBs are basically compiled to bytecode that has faster access to the DB structure (i.e. probably a C library).
;-)...
Now, contrast this to a modern scripting language (PHP4, ASP) or Java --a high level language (not unlike a SPL) that also compiles to bytecode. The performance difference here is access to the data structure: in all the languages above (ASP, PHP, Java) the way the DB is accessed (i.e. the speed of the JDBC, ODBC driver or PHP module) is what determines the speed of access to the DB.
In other words, there really isn't much of a difference between using an SPL in a DB or an external scripting language that has fast access to the DB data --e.g. the PHP module for MySQL. I think what confuses you here is that Oracle has *never* given a C library (or anything similar) for access to the DB structure, forcing everybody to use their proprietary SPL.
IMHO, the future lies with highly developed, open and popular languages (PHP and Java being my favorites here) that have C-level access to data structures *directly*. I.e. you could potentially get rid of SQL (or make SQL another language with access to the C library) and, more importantly you could have different types of data structures in the same application: e.g. a very fast read-only DB file (think MySQL) and a robust object-store DB (think Postgres) that look and feel the same to the end developer (the PHP dude). If anybody wants to start an OSS project like that, count me in
engineers never lie; we just approximate the truth.
GPS is so prevalent in the 'new', 'modern' battlefield that a device like this makes a lot of sense and I am sure that a lot of militaries have already built their own --or if not, they are starting up similar projects as we type...
Just some potential uses of a GPS jammer: Handheld and dashboard-mounted GPS is used all the time in tanks/helicopters/ships and by troops in the field. In most cases (i.e. outside of the US) these are *commercial* grade GPS, not US Military-grade GPS --i.e. they will be much less resistant to jamming.
The US Military, OTOH, has put so much faith into GPS, it's now using it to guide smart bombs and cruise missiles... so, you can see, the fact that the US Air Force itself has proven that it is feasible to jam GPS with COTS (commercial off-the-shelf) technology will be a HUGE deal to the defense planners of the world...
Now, I am not a EE, much less a DSP/GPS specialist, but from my knowledge of the system I am guessing that: a) the system described above won't be much use against fast-moving airborne GPS (fighters), and b) US Military-grade GPS can be affected just as effectively --as I believe that the US Navy is using an encoded higher time-resolution signal to achieve more accurate measurements. But if the signal is jammed, encryption won't be much use, right?
engineers never lie; we just approximate the truth.
Maybe I am being naive, here, but without copyright enforcement how could a GPL author *enforce* derivative works to be under the GPL?
It seems to me that w/o copyright law, the effective use of any open-source software would allow BSD-like freedoms rather than GPL. I don't want to start the holy war again here; I may just be misunderstanding the GPL. I do think both licenses have their places and their uses...
engineers never lie; we just approximate the truth.
Any specs on those? I mean, the technology sounds great, but how *fast* is MRAM/VRAM?
engineers never lie; we just approximate the truth.
... what's the "largest private supercomputer" Celera claims to have used? (quote is from the Wired article). Anybody got any info?
engineers never lie; we just approximate the truth.
Excellent points; let me add a coupla more: I am not sure what 'real time mathematical computations' means here. CPUs that can crunch complex mathematical systems in real time, are usually developed by DARPA and cost millions per unit (I am referring to jet fighter avionics packages; usually TI or Rockwell chips).
Now, if the poster is referring to mathematical problems (but not 'real time', more like 'solved in a reasonable time'), the above post is right on the money: do not buy an SMP system --at least not an x86 SMP system (I don't have any exprience with Alphas). The problem with x86 SMPs is bus speeds, i.e. communication between CPUs on the same board. Using fast network interconnects (gigabit speeds) you can usually get better performance between boxes than between CPUs for some SMP systems (particularly quads and 8-ways). Duals are not as problematic, so for compactness' sake they might worth the $$$...
Keep in mind though, this is not the way things *should* be, it's just the state of the art --which sucks right now in x86-land. With better motherboards coming up (not to mention better SMP support by all the different OSes --the new Linux kernels seem to have solved context switching problems that were killing SMP machines, for example), eventually SMP machines will be the way to go...
engineers never lie; we just approximate the truth.
This is one of the best Web-hoaxes I've found (well, so far ;-):
;-)...
A guy created this fake (and not really real-looking) commercial site selling the "IDChip" which was described (on purpose) a lot like the "sign of the Beast" from Revelation. He got so many e-mails and death-threats from religious fanatics, he had to shut down and reveal the hoax in less than a week. Definitely worths the click to his "letters" section
engineers never lie; we just approximate the truth.
Privatize NASA? y'all on drugs? ;-)... In a sense NASA is *already* privatized: when it spends a few hundred million dollars on an X plane that validates a technology some company (Boeing, Lockheed, Northrop --the only ones left really) will build an aircraft around, the money does eventually flow to the private sector. The single greatest example is perhaps the X-33, where NASA is essentially subsidising the development of a commercial launch vehicle.
But what most of the readers here fail to realize is that NASA *must* stay as a government agency for both scientific and economical reasons: Scientific, becuase as others mentioned, NASA has probably the best 'research ethic' in the world. The people there are more free to pursue their own research interests than they would in a corporate R&D facility or in a (corporate-subsidized) research university.
Most importantly though, NASA cannot *afford* to be private; the financial threshold for entry into the aeronautical or space business would have any Valley VC running scared... most big commercial aerospace projects (a good example is the 777) don't pay themselves off until a *decade* or so into production. Boeing is large enough (and the governments behind Airbus can tax enough) to keep those huge cash reserves around, but the stock market doesn't have that kind of patience, especially this market of 6-months-from-incorporation IPOs...
What is truly sad is that most of this wealth is being created by companies largely immitating one another, while true innovators are punished because they are 'sinking' their profits into R&D (who's 'hotter': VA or IBM? Lucent or ?)
engineers never lie; we just approximate the truth.
While I agree with almost everything you said (including the part about Linux being an excellent imitator and a rare innovator), I am tired of seeing the same premise being used again and again wrt OSS: you don't necessarily need a buncha 'lone hackers' hacking away at a problem.
Let's suppose that a fairly good-sized company came out with an open-sourced RDBMS/OLAP framework, that has all the groundwork to be fast and extensible. I am sure there are a few companies out there that would benefit to contribute to such a project for their own uses... Why can't OSS act as a framework and collaboration scheme, instead of just a toy for hobbyists?
engineers never lie; we just approximate the truth.
Not all DSS environments are/should be read-only. My employer deploys one of the largest (if not the largest) read-write DSS client-server application.
;-)...
Transactions/Rollback are not critical (we have our own rollback solution over Acumate, made by Kenan) but in a read-write environment, they sure are good to have around.
OTOH, you're right; in a DSS environments reads are always way more common than writes, so a rollback layer could actually be preferrable to a built-in transactional functionality.
So, forget about transactional control, it's not even essential; are there *any* OSS OLAP apps out there? they sure would make a nice toy
engineers never lie; we just approximate the truth.
I've done some research on this topic, and by far the most open/tested OSS RDBMS out there is PostgresSQL, which is actually based on the same tree from which a commercial RDBMS, Ingres, was spawned. However, I do not believe that Postgres is solid/fast enough for enterprise level applications yet (mind you, this is from reading a lot of Usenet and Web opinions on it, not personal experience, so YMMV).
Since I am a DSS ("Data Mining") guy though, I am more interested in an extension to your question? is there any decent OSS OLAP/DSS DB system out there that can handle multiple dimensions, transactions, partitioning, ? If not, how many people would be interested in one?
engineers never lie; we just approximate the truth.
Huh? Finite differences are still very widely used; most (like 80%+) of CFD is done using finite differences. Actually, in any model that you're examining a finite volume of space, rather than an object, you're most likely using finite differences (i.e. fluid problems, including AFAIK weather simulation).
Finite elements are mainly used for objects/mechanisms, particularly structures analysis (incl. car simulation) and manufacturing (metal stamping).
engineers never lie; we just approximate the truth.
Unix will not 'die'; neither will DOS, or MacOS, or Windows --any technology that it's innovative and gains enough mindshare lives on in other technologies. As long as a philosophy, concept of feature is liked enough, people will re-implement it under different systems... Do you forget that Linux was a Unix re-write?
Sadly, it seems that things aren't evolving as fast as they could. Linux *is* a Unix rewrite, and it's still not that much better than its foundation. NeXTStep re-implemented Unix a decade ago and it did a much better job --so much so, that its successor Mac OS X has still a big technological edge...
I wonder if the Linux community can look ahead far enough to stop worrying about backwards compatibility with older Unices and start innovating in the fundamentals of the OS. Security, administration, configuration, maintenance, documentation and quality of service are hopelessly krufty and kludgy in most Unices and Linux too.
There was a point that Linux needed to emulate its siblings, to remain relevant and useful. But in the next few years it's quite possible that Linux will become the dominant Unix-clone. Compatibility and tail-light chasing be damned --we need to innovate.
engineers never lie; we just approximate the truth.
I am not surprised by the fact that the US intelligence agencies perform industrial espionage. What appals me is the self-congratulating excuse that the US has to do it because European companies are not good enough to win contracts on their own merits, so they have to stoop to bribery.
I am European... I've worked and lived in the US. I've also lived and worked in Europe. I've been close enough to billion-dollar contracts to have an idea what's going on. For anyone to claim that somehow US corporations are the keepers of corporate morality in the international marketplace is ridiculous...
So, does anybody out there remember what the term "Banana Republic" actually meant before it became a clothing store? Does anyone remember what the greatful Saudis did after the end of the Gulf War? Mayhaps they went ahead and bought a buncha F-15s? didn't they also let Boeing have a huge contract of airliners for the state-owned airline?
Now, I ain't saying that somehow American companies are better or worse than British, French or Dutch ones; but to claim that they are indeed so much so more moral as to justify these actions (regardless of the fact that really everybody does it) is absurd.
engineers never lie; we just approximate the truth.