"* lets you manipulate a client-side database" HTML 5 has SQL databases for client-side storage.
"* lets you establish a socket connection to a server" So long as it's http, you can do a lot of advanced async RPC operations, including poll-based message notifications.
"If you're teaching yourself javascript or html5 then the truth is that you are probably wasting your time." Cause you know, the marketing end of a web-site doesn't need to access the 99.9% of customers or anything.
You do realize WHY javascript in browsers don't provide native access don't you? Any why node.js does.. How many emergency flash updates have been pushed in the last year? And see if you can find any that were related to javascript security holes.
Have you ever written to a SOA before? It's not exactly the hardest thing in the world to abstract.. It takes like 20 lines of Java code to swap one data-store for another (and I'm talking flat-binary-file, flat-XML-fle, flat-CSV-file, sqlite, hsqldb, mysql, postgres, oracle, NoSQL vendor A,B,C).. It's called coding to abstraction layers.. And guess what, there are already tools that abstract all the major java vendors (elastic bean-stalk, app-engine, etc).
You make it sound like VHDL is harder to write than assembly.. I assure you it's more expressive than that primitive sequential crap that assembly (and it's higher-level derivatives) forces you to think in.:) And every bit as modular.
I'll take your sarcasm and raise it. Clearly you haven't done much embedded programming. Where you almost don't even notice when switching back and forth between C and assembly - and often you're frustrated with the limitations and hackish work-arounds that the high-level language forces you to make.. Why do I need to divide then modulate when one assembly instruction is all I need?:)
classes in javascript are hodge-podge at best, hard-to-read. Inheritence is not worth the trouble. The undefined v.s. null v.s. false-valued is a bug-death-trap. To a lesser degree, equality. scoped/packages are a hack at best. These are all things the language can be forced to do against it's will, and if you exclusively deal with libraries like jQuery you can usually avoid it. But ultimately if you want to write re-usable code, then you have to pick a hackish paradigm. This allows you to write elegant looking software with fewer lines of code (e.g. lower risk of bugs). I see a couple gotcha's "->" v.s. "=>", the "@sym", and a couple other places where debugging will be hell. Then there's the lack of editor support, potential errors in the compiler. But it does make the language more palatable.
If you're already fine with nondeterminisitic 'this' values, and are comfortable with your own thing with modular coding, then this doesn't really bring much to the table for you. But I've read my fare share of unreadible javascript code, and normalized structure is not something that would hurt the language/platform.
Well, you're half right.. It went from main-frame+ASCII terminal to peer-to-peer power-houses, back to COTS centralized hardware (trying to reproduce mainframe without the mainframe) + HTML/Browser.. Now I think it's almost found it's happy medium, proprietary mainframe components (netapp-type storage appliances + cisco + cloud-farms (160-core CPU blades) + VMware-type) for the sharable data + javascript 'thick client'. By thick, I mean gmail takes about 250Meg of RAM these days.
The reason I like the current division is that peer-to-peer is inherently unscalable (unless you're willing to use eventually consistent models, where eventually, here, might be on the order of years). So you take ONLY the portion that needs to be shared and centralize it.. Then farm out the rest to the client.
iOS/android/chrome-OS apps are basically where HTML+Javascript are too limiting. iOS HTML extensions allow swiping events whereas the others don't do it as expressively, so there currently is an edge for embedded apps.. I'm not a fan of them at all.. I'd rather customized HTML that can survive network outage.. Namely if you hit the page and the network is down, the browser just loads the old page.. The use of HTML 5 sql tables means you have off-line storage already.
I think maybe the android Java or the Objective-C binaries can save a little power v.s. a complex javascript system - but I'd be curious to see how true that really is.
Obviously the main thing [evil] Apple wants, is what [evil] MS wants, which is vendor lock-in.. So the richness of the iPhone experience is through their graphical widget API.. No reason they couldn't made them as HTML extensions or javascript libraries, EXCEPT then other platforms would get their capability for free.. So sad..
But it's a matter of opinion whether this is an error or not. If I've subclassed a method and my base class one day implements it too with the same name with a protected or public method then it's fine... If they implement it as private then (and I can't remember which happens) you either fail hard or it calls it's local private - both of which are fine. If you're extending 3rd party code you MUST take into account version mismatch issues - namely you must build a robust packager. If you're extending your own code, then there's no sense for bad taste.
That being said, I have made judisciuos use of the @Override method to do half of what you've described - the half that I think is more important.
And why exactly does a production DB need to allow user-level account access? And why would a dev/test DB care about passwords? Are we still living in a day where client apps have passwords directly into the DB as opposed to having a password file in the DB that allows access to the higher level app?
Because show [VERBOSE] XYZ like 'foo%bar'; is so less intuitive than \dl \dt \df \l And to think, using something that looks like SQL inside a SQL maintenance tool.. arrogant bastards. Don't they know using notepad on 4 config files and reloading the server is the proper way to administer things.
Two things. 1) fdatasync on 100 files is going to have a higher probability of updating the inode record (because their individual file sizes will have likely grown) - I'm talking to you postgres too. Thus doubling the number of dirty blocks per synchronous commit. 2) Mysql gives you the option of 1 file, a raw partition (i.e./dev/vg0/INNODB1 2 3, etc), one large regular file or hundreds of little files.
I tend to choose the hundreds of little files so I can see last-modified time-stamps on my literally hundreds of aging custom databases. But I definitely prefer the consolidated uber-file for performance reasons.
The idea of a database is that the disk belongs to a single process.. So I never understood this idea of recovering deleted disk space. In fact, I'd prefer to pre-allocate the whole damn partition or at least, on an extent-based file-system the ability to have a defragmented single-mathmatically-block-address-lookup storage file. Cold randomly scattered 4KB randomly allocated sectors require log_2k(n) disk lookups per read/write.. contiguous extends take precisely 1 highly-cached lookup.
Maybe I'm missing something, but I don't see how that's possible. Hibernate is idiot-simple when you have a single table of primitive types. I can write my own adaptor that serializes the entire row contents into a blob, then inject that into a RDBMS or key-value blob-store identically. In fact, the RDBMS will probably do this faster because it has many years of disk-oriented (memory is too small) code, v.s. most NoSQL solutions that are in-memory optimized and page-to-disk bolted on. If you use a BigTable or couchDB javascript document as your serialization, then you're straight back to explicit table land.. Namely because your Hibernate schema definition is rigid (while your BigTable/couchDB definition is not) - but you're limited by the weakest link.
The power of a CouchDB documents is in writing custom filters to translate the data. The power in BigTable is in it's efficient 1-to-many storage. Neither of which, again are leveraged by Object oriented solutions (save perhaps a dynamic scripting language like groovy).
I'm not disparaging NoSQL solutions - but I don't see a one-hat-fits all mold
Haha, only if you control the runtime.. You're only recently reliably able to compile against 1.5 and publish centrally. I STILL see tons of dual deployed open-source projects.. X and X-j5. Let alone compiled against java6 - why risk it? Again, unless you control the runtime.
You'd have to be doing something pretty hokey for this to be an issue. OutputStream maybe - since people wrap those all the time. Link-time, the only problem I can see is if you happened to have the same input signature but a different return type - as that would normally be a syntax error - the class-loader validator would probably fail hard.
That being said.. How else could you handle this? Contain both version 1.2 OutputStream AND version 1.7 ? Not seeing that as a practical.
I've definitely been hit with version mismatches - but they're almost always a missing method errors. Now things like maven really solve this problem nicely (albeit not perfectly).
Because editors that perform code-refactoring are hard pressed to keep up with the syntax of the week. When you have 1M people coding towards a common base platform, then you can quickly build off each other's successes (both open-source and commercially). If EVERYBODY is going their own direction, you get what we've had for the past 50 years in CIS.. Stagnation, redoing the same old algorithms and libraries over and over again.. How many times must I re-learn a CRUD dialog? stdin, curses, X, windows 3.0, Mac, HTML + tables. HTML + CSS, HTML + Javascript + Ajax, jQuery.xxx. Flash. AWT, SWING, TK, applets, blackberry-dialogs, android-dialogs, silverlight, GWT. JSP/JSF/taglets/webworks/spring-MVC/stripes/seam. Objective-C dialogs? I'm sick of it I tell you. And being an old foggie, I've missed out on like 10 rails-style builders. I feel like I'm only ever able to write hello world's level of complexity. Until we can actually start building instead of rebuilding (with the vast majority of human resources), AI is perpetually going to be 100 years away.
I know some people will prefer a php, ruby, C++ (I rule out OS-targetted languages - namely those who's vast wealth of libraries and development support are specific to a given platform - like Objective-C and.NET), but I've felt the most productive with large / advanced algorithms in Java. 100,000 lines of code in java is FAR more error proof than C++, and I would venture to say ruby/php as well (given that they are so loose in syntax you can't validate / refactor them safely). And yes, I know that 40,000 lines of ruby is equivalent to 100,000 lines of java - but lack of safe refactoring is still an issue. I also rule out the lack of modularity of common PHP packages. Perl/Python/Java/C++ allow safe compartmentalization. Perl/Java (and I assume Python) very nicely allow safe module loading (e.g. if I don't have a module, I can gracefully take alternate action) - I can do so safely in multi-threaded environments (less so with Perl/Python). I can package and deploy the code centrally or in a private network at zero extra cost/technical-risk (sshd +/etc/password + apache == secure java maven-module repository).
If I need to create a project for someone, and I don't want to have to re-invent the wheel on almost any algorithm. If I want it to farm out to 50 developers, but I don't want to have to invent a project-management beuracracy.. If I need the project to scale to 500 machines - but I don't want to have to invent a network fabric. If I want to maximize high-CPU counts (e.g. 24 per machine) on complex image/video-processing/batch-processing (and I may or may not want to risk C++ linkage). If I want intricate timing, timeouts, locking.. And more importantly, I want to delegate out to other developers of questionable skill level - and have THEM properly handle threading, locking, timeouts, etc.
Then today, it's a no brainier for me to recommend java. Yes individual languages excel at some aspects of the above (PHP,Ruby,C++), but none do all sufficiently - at least not without very careful coordination with all the developers.
But once it gets to the UI - all best are off, sadly.
mdadm + drbd + lvm + ext4 (throw crypto somewhere in there too). I've found the layers to be frustrating when deviating from initial install. And I've also found installation of new machines to rarely support the particular layering model I'm interested in. So I typically have to do a complex post-install reconfiguration. If, instead the layers were flatened (and supported zfs style RAID-5 write-hole elimination), my life would be make significantly easier. I'm not saying btrfs's particular architecture, but the ability to have the 'layers' work in tandom instead of invocation-level layers. Define plugable aspects of block mapping that are part of a common OS operation.
I doubt this would be as efficient as a monolithic flattened file-system, nor as robust as monolithic or even layered (as the number of combinations of event-condition grows factorially). But when I design software, there is a careful balance of layering v.s. aspect-orientation. Service X can do 10 things, each of which are configured at load-time as delegates. Of which 4 things might be noops for any given configuration.
If Gov has to raise taxes or print money to pay a worker to dig a ditch, or do a job that could have saved money over a 5 year period through automation (produced domestically), then I'm not sure that job was worth saving - as it constitutes a burden on remaining workers.. Now, MOST automation tools today have a large foreign manufactured aspect, and thus contribute to trade deficits and don't trade domestic unskilled for comparable skilled labor. And many automation systems are far more expensive than a 5 year recoup-cost. But you have to take into account the FULL cost of employment, including government sweet-heart retirement benefits. Sadly most government agencies assume they can get an AVERAGE 7% yield on pension funds, and thus find themselves in hot water with monumental debt 30 years later, so I suspect that job for job, automation is probably cheaper than direct employment. With outsourced employment, it's generally more expensive up-front, but at least you avoid future liabilities.
Obviously my intended response was that automation merely shifts the demand for direct menial labor to skilled labor in constructing/distributing/marketing/installing/managing automation systems, along with educational requirements for the next generation of automation. In general, the added sociatal productivity, and the propensity to require more and more higher levels of education within an otherwise wealthy society are, IMHO a good thing. I'd rather solve a problem once so that one man can do 1,000 people's jobs, where possible, as it increases the complexity of a type of job that can be accomplished. We've proven we can get to the moon with brute force.. But we're a long way away from producing a life-systaining biosphere on a satylite.
Government spending is complex - do you focus exclusively on defense, infrastructure? Do you subsidize? Do you 'invest' in education? Or, like in the past 10 years, exclusively react, because there is no political will to be strategic. Republicans 'punt' by just saying someone else will fix the problem - lets give them more money. Democrats haven't provided cohesive ideas beyond 'spend us out of the recession'.
Depends on the working set size. A 4-way RAID-10 controller is like $200. So with 4x2TB at roughly $150/disk, that's: 4TB of storage at $800
For RAID-10 on 500GB hybrid SSD platters with 64GB SSD cache, you'd need a 16-way RAID-10 controller: $1k
16x $300 + $1k = $5,800 That 16-array only gives you randomly allocated 512GB of SSD (maybe a little higher if you interleave which half of the RAID-1 and thus separately allocate SSD mappings - though this can't be controlled by the OS so it's largely random).
IF, instead you explicitly allocated indexes / hot tables onto a quartet of 128GB SSDs (say $300 each). Then we could have: RAID-4 controller with 4x2TB drives: $800 + RAID-4 controller with 4x128GB drives: $1,400 Total: $2,200
Less cost per HD failure, less power consumption, and more targeted index disks (SSD) and journaled disks (HD). So indexes are guaranteed more efficient than on the mixed-mode storage, journals are equal in performance, and data-disks are slightly slower on pure HDs. We have slightly less SD capacity, but there's no guarantee the firmware will properly guestimate what data goes into SSD (same issue as cache-pollution).
You're still going to want 8GB to 128GB of RAM on any DB server. And if you're up to 128GB of RAM, then the SSD is of slightly less usefulness (especially on read-mostly nodes).
For non DB loads, RAID-5/6 might be a more cost effective solution, and thus those 64GB sections can start to add up to a usable working set. Hot regions of video metadata files can speed up drastically, while the HD's can potentially be leveraged for large spanning reads/writes (though don't know if you'd have cache-pollution).
Lastly, something like WAFL on netapp isn't going to leverage the hybrid at all, because it's specifically journaling all data (e.g. translating random writes into remapped linear writes, with explicit fixed-sized SSD mapping tables / journals).
Letting the OS do it is great in theory. I think ZFS supports this concept. Brtrs maybe in 10 years. Maybe MS will support it soon (as a reason to upgrade). The problem for me as a user of the HW.. What if the SSD went bad? what data did I lose? What if I want to upgrade the disk? Previously the RAID HW or bare OS was very explicit about what went where. Do I trust that I can just clone a disk with a newer partition.. Or relocate the disk to a new machine? If you think of it like RAID-0, then obviously it's no different. But to the casual user, it seems to be more complicated - since the HD 'seems' to store all your data, and thus the SSD is just a 'cache', but in reality it's not necessarily fully committed after hard shutdown.. I can just see the user complaints down the road.
For the initiated, I'm sure it's fine though.
As for the laptop 'low power mode'.. My HD's were usually powered-down most of the time.. If the HD detects wake-up triggers and moves those data blocks over to SSD, then over time the need to wake up the HD reduces over time. So while statistical in nature, I do see value-add.
You're implying write-intensity. I don't think SSD's have any faster write speeds than HD's (at least linearly). Further, most write operations can be journal'd / buffered. It's the random read speed or read-modify-write that's killer. The question is begged, if 4GB of dedicated RAM cache (e.g. on a 6/8GB RAM installation) is insufficient for your RMW critical work-load, then perhaps 64GB is enough (e.g. if no more than 1/10th of your data is critical path). This seems like a reasonable assumption for today's common problems.
However, it personally is far from enough for any workload I've encountered in 6 years. My critical volume is on the order of 100GB to 500GB (random disk-seek on a multi TB of indexed data - e.g. hashed indexes). Though if I KNEW a specific table only had 64GB of fast-path retrieval, I could possibly specially allocate it's index. Just seems like a lot of work to fine-tune. But it would certainly be nice to know that, unlike a pure SSD solution I COULD grow beyond the size-constraints of the SSD. I think THAT is the target market (along with fast boot laptops, etc).
As for write-wearing on the SSD. At least intel had some intelligent write-leveling - didn't see whether this solution did it as well. Given the need for block-remapping, I'm assuming the answer is yes.
The problem is that people tend to focus on single-threaded designs for 3rd party libraries.. Then when those libraries get linked to larger libraries (or main apps) which are MT, then the whole world comes crashing down. Now you have to treat every function call of the ST-library as a critical region.
Thus while YOU may not care about MT, you should strive to make all your code reentrant at the very least. To whatever degree this allows contention-free memory access (e.g. ZERO global variables). This future proofs your code.
Use modern inversion-of-control programming models - don't own your dependencies, but instead require factories for the objects you actually need. You read-only value-objects where-possible, factory-IOC singletons where possible, stack-based allocation, minimal co-mingled data-structures. If you have the ability to leverage Garbage collection, do so for co-mingled structures (or maybe explicit reference counting).
This may actually slow your library down and grow it's size slightly.. But you'll have less coupled / more modular code, which can't be a bad thing. And you'll be more likely to be MT-safe out of the box.
Then if tomorrow you find you can parallelize some aspect (possibly by using message-passing worker threads), or that some 3rd party can do so TO your work, you'll get performance for free.
While you're correct from a temporarily practical measure, I disagree in theory. OS theory 20 or more years ago was about one very simple concept.. Keeping all resources utilized. Instead of buying 20 cheap, slow full systems (at a meager $6k each), you can buy 1 $50k machine and time-share it. All your disk-IO will be maximized, all your CPUs will be maximized, network etc. Any given person is running slower, but you're saving money overall.
If I have a single 8 core machine but it's attached to a netapp disk-array of 100 platters over a network, then the latency means that the round trip of a single-threaded program is almost guaranteed to leave platters idle. If, instead I split a problem up into multiple threads / processes (or use async-IO concepts), then each thread can schedule IO and immediately react to IO-completion, thereby turning around and requesting the next random disk block. While async-IO removes the advantage of multiple CPUs, it's MASSIVELY error-prone programming compared to blocking parallel threads/processes.
A given configuration will have it's own practical maximum and over-saturation point. And for most disk/network sub-systems, 8 cores TODAY is sufficient. But with appropriate NUMA supported motherboards and cache coherence isolation, it's possible that a thousand-thread application-suite could leverage more than 8 cores efficiently. But I've regularly over-committed 8 core machine farms with 3 to 5 thousand threads and never had responsiveness issues (each thread group (client application) were predominantly IO bound). Here, higher numbers of CPUs allows fewer CPU transfers during rare periods of competing hot CPU sections. If I have 6 hot threads on 4 cores, the CPU context switches leach a measureable amount of user-time. But by going hyper-threading (e.g. doubling the number of context registers), we can reduce the overhead slightly.
Now for HPC, where you have a single problem you're trying to solve quickly/cheaply - I'll admit it's hard to scale up. Cache contention KILLS performance - bringing critical region execution to near DRAM speeds. And unless you have MOESI, even non-contentious shared memory regions run at BUS speeds. You really need copy-on-write and message passing. Of course, not every problem is efficient with copy-on-write algorithms (i.e. sorting), so YMMV. But this, too was an advocation for over-committing.. Meaning while YOUR problem doesn't divide. You can take the hardware farm and run two separate problems on it. It'll run somewhat slower, but you get nearly double your money's worth in the hardware - lowering costs, and thus reducing the barrier to entry to TRY and solve hard problems with compute farms. amazon EC anyone?
Do you debug and maintain 'cd'ing directories? How about opening a log file with a text editor? How about debugging your excel file? Why not? Because the input and output are reproducable and they are one-time events. If I'm trying to ask the question - how many log files did this application just produce.. I can A) open up a stupid gui and manually count them (if I'm lucky, I can sort by extension - but good luck if they're spanning multiple directories) B) I can do a file-system search for *.log files, and manually count them. C) Write a one-liner such as:
find -name '*.log' | wc -l
Now if I wanted to add up their file sizes:
find -name '*.log' | xargs ls -l | awk ' { $sum += $F[5] } END {print $sum} '
This is the basis of shell programming - BUT when you start adding conditional, it becomes very unnatural
for x in $(find -name '*.log'); do [[ -f $x ]] && echo "Found $x"; done
Nothing there denoted the 'if statement'. Enter perl. The ability to run all these shell-like commands, AND leverage all of 'awk' and 'sed's text-processing powers, AND have a full blown turing complete language.
Go through 4 more revisions and you create the one-time glue of the internet.
Perl is a very natural language if you're use to sh, bash, sed, awk, grep and friends. It looks foreign to windows people because batch files have equally bad syntax. And of course straight-programmers that have never had to script in their lives look down on such languages as beneath them I'm sure - much like menial labor.
who said sub-atomic? I said differential equations.. EE 301 type course..Simple circuit modeling equations. It's not precise, but it gives you appropriate steady-state and transition probability equations between coupled modules or within modules..
Slashdot Mirror
"* lets you manipulate a client-side database"
HTML 5 has SQL databases for client-side storage.
"* lets you establish a socket connection to a server"
So long as it's http, you can do a lot of advanced async RPC operations, including poll-based message notifications.
"If you're teaching yourself javascript or html5 then the truth is that you are probably wasting your time."
Cause you know, the marketing end of a web-site doesn't need to access the 99.9% of customers or anything.
You do realize WHY javascript in browsers don't provide native access don't you? Any why node.js does..
How many emergency flash updates have been pushed in the last year? And see if you can find any that were related to javascript security holes.
Have you ever written to a SOA before? It's not exactly the hardest thing in the world to abstract.. It takes like 20 lines of Java code to swap one data-store for another (and I'm talking flat-binary-file, flat-XML-fle, flat-CSV-file, sqlite, hsqldb, mysql, postgres, oracle, NoSQL vendor A,B,C).. It's called coding to abstraction layers.. And guess what, there are already tools that abstract all the major java vendors (elastic bean-stalk, app-engine, etc).
You make it sound like VHDL is harder to write than assembly.. I assure you it's more expressive than that primitive sequential crap that assembly (and it's higher-level derivatives) forces you to think in. :) And every bit as modular.
I'll take your sarcasm and raise it. Clearly you haven't done much embedded programming. Where you almost don't even notice when switching back and forth between C and assembly - and often you're frustrated with the limitations and hackish work-arounds that the high-level language forces you to make.. Why do I need to divide then modulate when one assembly instruction is all I need? :)
classes in javascript are hodge-podge at best, hard-to-read. Inheritence is not worth the trouble. The undefined v.s. null v.s. false-valued is a bug-death-trap. To a lesser degree, equality. scoped/packages are a hack at best. These are all things the language can be forced to do against it's will, and if you exclusively deal with libraries like jQuery you can usually avoid it. But ultimately if you want to write re-usable code, then you have to pick a hackish paradigm. This allows you to write elegant looking software with fewer lines of code (e.g. lower risk of bugs). I see a couple gotcha's "->" v.s. "=>", the "@sym", and a couple other places where debugging will be hell. Then there's the lack of editor support, potential errors in the compiler. But it does make the language more palatable.
If you're already fine with nondeterminisitic 'this' values, and are comfortable with your own thing with modular coding, then this doesn't really bring much to the table for you. But I've read my fare share of unreadible javascript code, and normalized structure is not something that would hurt the language/platform.
Well, you're half right.. It went from main-frame+ASCII terminal to peer-to-peer power-houses, back to COTS centralized hardware (trying to reproduce mainframe without the mainframe) + HTML/Browser.. Now I think it's almost found it's happy medium, proprietary mainframe components (netapp-type storage appliances + cisco + cloud-farms (160-core CPU blades) + VMware-type) for the sharable data + javascript 'thick client'. By thick, I mean gmail takes about 250Meg of RAM these days.
The reason I like the current division is that peer-to-peer is inherently unscalable (unless you're willing to use eventually consistent models, where eventually, here, might be on the order of years). So you take ONLY the portion that needs to be shared and centralize it.. Then farm out the rest to the client.
iOS/android/chrome-OS apps are basically where HTML+Javascript are too limiting. iOS HTML extensions allow swiping events whereas the others don't do it as expressively, so there currently is an edge for embedded apps.. I'm not a fan of them at all.. I'd rather customized HTML that can survive network outage.. Namely if you hit the page and the network is down, the browser just loads the old page.. The use of HTML 5 sql tables means you have off-line storage already.
I think maybe the android Java or the Objective-C binaries can save a little power v.s. a complex javascript system - but I'd be curious to see how true that really is.
Obviously the main thing [evil] Apple wants, is what [evil] MS wants, which is vendor lock-in.. So the richness of the iPhone experience is through their graphical widget API.. No reason they couldn't made them as HTML extensions or javascript libraries, EXCEPT then other platforms would get their capability for free.. So sad..
But it's a matter of opinion whether this is an error or not. If I've subclassed a method and my base class one day implements it too with the same name with a protected or public method then it's fine... If they implement it as private then (and I can't remember which happens) you either fail hard or it calls it's local private - both of which are fine. If you're extending 3rd party code you MUST take into account version mismatch issues - namely you must build a robust packager. If you're extending your own code, then there's no sense for bad taste.
That being said, I have made judisciuos use of the @Override method to do half of what you've described - the half that I think is more important.
And why exactly does a production DB need to allow user-level account access? And why would a dev/test DB care about passwords? Are we still living in a day where client apps have passwords directly into the DB as opposed to having a password file in the DB that allows access to the higher level app?
Because
show [VERBOSE] XYZ like 'foo%bar';
is so less intuitive than \dl \dt \df \l
And to think, using something that looks like SQL inside a SQL maintenance tool.. arrogant bastards. Don't they know using notepad on 4 config files and reloading the server is the proper way to administer things.
Two things. /dev/vg0/INNODB1 2 3, etc), one large regular file or hundreds of little files.
1) fdatasync on 100 files is going to have a higher probability of updating the inode record (because their individual file sizes will have likely grown) - I'm talking to you postgres too. Thus doubling the number of dirty blocks per synchronous commit.
2) Mysql gives you the option of 1 file, a raw partition (i.e.
I tend to choose the hundreds of little files so I can see last-modified time-stamps on my literally hundreds of aging custom databases. But I definitely prefer the consolidated uber-file for performance reasons.
The idea of a database is that the disk belongs to a single process.. So I never understood this idea of recovering deleted disk space. In fact, I'd prefer to pre-allocate the whole damn partition or at least, on an extent-based file-system the ability to have a defragmented single-mathmatically-block-address-lookup storage file. Cold randomly scattered 4KB randomly allocated sectors require log_2k(n) disk lookups per read/write.. contiguous extends take precisely 1 highly-cached lookup.
Maybe I'm missing something, but I don't see how that's possible. Hibernate is idiot-simple when you have a single table of primitive types. I can write my own adaptor that serializes the entire row contents into a blob, then inject that into a RDBMS or key-value blob-store identically. In fact, the RDBMS will probably do this faster because it has many years of disk-oriented (memory is too small) code, v.s. most NoSQL solutions that are in-memory optimized and page-to-disk bolted on. If you use a BigTable or couchDB javascript document as your serialization, then you're straight back to explicit table land.. Namely because your Hibernate schema definition is rigid (while your BigTable/couchDB definition is not) - but you're limited by the weakest link.
The power of a CouchDB documents is in writing custom filters to translate the data. The power in BigTable is in it's efficient 1-to-many storage. Neither of which, again are leveraged by Object oriented solutions (save perhaps a dynamic scripting language like groovy).
I'm not disparaging NoSQL solutions - but I don't see a one-hat-fits all mold
Haha, only if you control the runtime.. You're only recently reliably able to compile against 1.5 and publish centrally. I STILL see tons of dual deployed open-source projects.. X and X-j5. Let alone compiled against java6 - why risk it? Again, unless you control the runtime.
You'd have to be doing something pretty hokey for this to be an issue. OutputStream maybe - since people wrap those all the time. Link-time, the only problem I can see is if you happened to have the same input signature but a different return type - as that would normally be a syntax error - the class-loader validator would probably fail hard.
That being said.. How else could you handle this? Contain both version 1.2 OutputStream AND version 1.7 ? Not seeing that as a practical.
I've definitely been hit with version mismatches - but they're almost always a missing method errors. Now things like maven really solve this problem nicely (albeit not perfectly).
Because editors that perform code-refactoring are hard pressed to keep up with the syntax of the week. When you have 1M people coding towards a common base platform, then you can quickly build off each other's successes (both open-source and commercially). If EVERYBODY is going their own direction, you get what we've had for the past 50 years in CIS.. Stagnation, redoing the same old algorithms and libraries over and over again.. How many times must I re-learn a CRUD dialog? stdin, curses, X, windows 3.0, Mac, HTML + tables. HTML + CSS, HTML + Javascript + Ajax, jQuery.xxx. Flash. AWT, SWING, TK, applets, blackberry-dialogs, android-dialogs, silverlight, GWT. JSP/JSF/taglets/webworks/spring-MVC/stripes/seam. Objective-C dialogs? I'm sick of it I tell you. And being an old foggie, I've missed out on like 10 rails-style builders. I feel like I'm only ever able to write hello world's level of complexity. Until we can actually start building instead of rebuilding (with the vast majority of human resources), AI is perpetually going to be 100 years away.
.NET), but I've felt the most productive with large / advanced algorithms in Java. 100,000 lines of code in java is FAR more error proof than C++, and I would venture to say ruby/php as well (given that they are so loose in syntax you can't validate / refactor them safely). And yes, I know that 40,000 lines of ruby is equivalent to 100,000 lines of java - but lack of safe refactoring is still an issue. I also rule out the lack of modularity of common PHP packages. Perl/Python/Java/C++ allow safe compartmentalization. Perl/Java (and I assume Python) very nicely allow safe module loading (e.g. if I don't have a module, I can gracefully take alternate action) - I can do so safely in multi-threaded environments (less so with Perl/Python). I can package and deploy the code centrally or in a private network at zero extra cost/technical-risk (sshd + /etc/password + apache == secure java maven-module repository).
I know some people will prefer a php, ruby, C++ (I rule out OS-targetted languages - namely those who's vast wealth of libraries and development support are specific to a given platform - like Objective-C and
If I need to create a project for someone, and I don't want to have to re-invent the wheel on almost any algorithm. If I want it to farm out to 50 developers, but I don't want to have to invent a project-management beuracracy.. If I need the project to scale to 500 machines - but I don't want to have to invent a network fabric. If I want to maximize high-CPU counts (e.g. 24 per machine) on complex image/video-processing/batch-processing (and I may or may not want to risk C++ linkage). If I want intricate timing, timeouts, locking.. And more importantly, I want to delegate out to other developers of questionable skill level - and have THEM properly handle threading, locking, timeouts, etc.
Then today, it's a no brainier for me to recommend java. Yes individual languages excel at some aspects of the above (PHP,Ruby,C++), but none do all sufficiently - at least not without very careful coordination with all the developers.
But once it gets to the UI - all best are off, sadly.
Flame away..
mdadm + drbd + lvm + ext4 (throw crypto somewhere in there too). I've found the layers to be frustrating when deviating from initial install. And I've also found installation of new machines to rarely support the particular layering model I'm interested in. So I typically have to do a complex post-install reconfiguration. If, instead the layers were flatened (and supported zfs style RAID-5 write-hole elimination), my life would be make significantly easier. I'm not saying btrfs's particular architecture, but the ability to have the 'layers' work in tandom instead of invocation-level layers. Define plugable aspects of block mapping that are part of a common OS operation.
I doubt this would be as efficient as a monolithic flattened file-system, nor as robust as monolithic or even layered (as the number of combinations of event-condition grows factorially). But when I design software, there is a careful balance of layering v.s. aspect-orientation. Service X can do 10 things, each of which are configured at load-time as delegates. Of which 4 things might be noops for any given configuration.
cache-mapping, block filtration (e.g. encryption / checksumming / block striping (RAID-0/5)), write-block consolidation (e.g. disk-geometry elevators / RAID-Z), physical disk/offset block mapping (including remote-node replication), etc.
If Gov has to raise taxes or print money to pay a worker to dig a ditch, or do a job that could have saved money over a 5 year period through automation (produced domestically), then I'm not sure that job was worth saving - as it constitutes a burden on remaining workers.. Now, MOST automation tools today have a large foreign manufactured aspect, and thus contribute to trade deficits and don't trade domestic unskilled for comparable skilled labor. And many automation systems are far more expensive than a 5 year recoup-cost. But you have to take into account the FULL cost of employment, including government sweet-heart retirement benefits. Sadly most government agencies assume they can get an AVERAGE 7% yield on pension funds, and thus find themselves in hot water with monumental debt 30 years later, so I suspect that job for job, automation is probably cheaper than direct employment. With outsourced employment, it's generally more expensive up-front, but at least you avoid future liabilities.
Obviously my intended response was that automation merely shifts the demand for direct menial labor to skilled labor in constructing/distributing/marketing/installing/managing automation systems, along with educational requirements for the next generation of automation. In general, the added sociatal productivity, and the propensity to require more and more higher levels of education within an otherwise wealthy society are, IMHO a good thing. I'd rather solve a problem once so that one man can do 1,000 people's jobs, where possible, as it increases the complexity of a type of job that can be accomplished. We've proven we can get to the moon with brute force.. But we're a long way away from producing a life-systaining biosphere on a satylite.
Government spending is complex - do you focus exclusively on defense, infrastructure? Do you subsidize? Do you 'invest' in education? Or, like in the past 10 years, exclusively react, because there is no political will to be strategic. Republicans 'punt' by just saying someone else will fix the problem - lets give them more money. Democrats haven't provided cohesive ideas beyond 'spend us out of the recession'.
Depends on the working set size. A 4-way RAID-10 controller is like $200. So with 4x2TB at roughly $150/disk, that's:
4TB of storage at $800
For RAID-10 on 500GB hybrid SSD platters with 64GB SSD cache, you'd need a 16-way RAID-10 controller: $1k
16x $300 + $1k = $5,800
That 16-array only gives you randomly allocated 512GB of SSD (maybe a little higher if you interleave which half of the RAID-1 and thus separately allocate SSD mappings - though this can't be controlled by the OS so it's largely random).
IF, instead you explicitly allocated indexes / hot tables onto a quartet of 128GB SSDs (say $300 each). Then we could have:
RAID-4 controller with 4x2TB drives: $800
+ RAID-4 controller with 4x128GB drives: $1,400
Total: $2,200
Less cost per HD failure, less power consumption, and more targeted index disks (SSD) and journaled disks (HD).
So indexes are guaranteed more efficient than on the mixed-mode storage, journals are equal in performance, and data-disks are slightly slower on pure HDs. We have slightly less SD capacity, but there's no guarantee the firmware will properly guestimate what data goes into SSD (same issue as cache-pollution).
You're still going to want 8GB to 128GB of RAM on any DB server. And if you're up to 128GB of RAM, then the SSD is of slightly less usefulness (especially on read-mostly nodes).
For non DB loads, RAID-5/6 might be a more cost effective solution, and thus those 64GB sections can start to add up to a usable working set. Hot regions of video metadata files can speed up drastically, while the HD's can potentially be leveraged for large spanning reads/writes (though don't know if you'd have cache-pollution).
Lastly, something like WAFL on netapp isn't going to leverage the hybrid at all, because it's specifically journaling all data (e.g. translating random writes into remapped linear writes, with explicit fixed-sized SSD mapping tables / journals).
Letting the OS do it is great in theory. I think ZFS supports this concept. Brtrs maybe in 10 years. Maybe MS will support it soon (as a reason to upgrade).
The problem for me as a user of the HW.. What if the SSD went bad? what data did I lose? What if I want to upgrade the disk? Previously the RAID HW or bare OS was very explicit about what went where. Do I trust that I can just clone a disk with a newer partition.. Or relocate the disk to a new machine? If you think of it like RAID-0, then obviously it's no different. But to the casual user, it seems to be more complicated - since the HD 'seems' to store all your data, and thus the SSD is just a 'cache', but in reality it's not necessarily fully committed after hard shutdown.. I can just see the user complaints down the road.
For the initiated, I'm sure it's fine though.
As for the laptop 'low power mode'.. My HD's were usually powered-down most of the time.. If the HD detects wake-up triggers and moves those data blocks over to SSD, then over time the need to wake up the HD reduces over time. So while statistical in nature, I do see value-add.
You're implying write-intensity. I don't think SSD's have any faster write speeds than HD's (at least linearly). Further, most write operations can be journal'd / buffered. It's the random read speed or read-modify-write that's killer.
The question is begged, if 4GB of dedicated RAM cache (e.g. on a 6/8GB RAM installation) is insufficient for your RMW critical work-load, then perhaps 64GB is enough (e.g. if no more than 1/10th of your data is critical path). This seems like a reasonable assumption for today's common problems.
However, it personally is far from enough for any workload I've encountered in 6 years. My critical volume is on the order of 100GB to 500GB (random disk-seek on a multi TB of indexed data - e.g. hashed indexes). Though if I KNEW a specific table only had 64GB of fast-path retrieval, I could possibly specially allocate it's index. Just seems like a lot of work to fine-tune. But it would certainly be nice to know that, unlike a pure SSD solution I COULD grow beyond the size-constraints of the SSD. I think THAT is the target market (along with fast boot laptops, etc).
As for write-wearing on the SSD. At least intel had some intelligent write-leveling - didn't see whether this solution did it as well. Given the need for block-remapping, I'm assuming the answer is yes.
The problem is that people tend to focus on single-threaded designs for 3rd party libraries.. Then when those libraries get linked to larger libraries (or main apps) which are MT, then the whole world comes crashing down. Now you have to treat every function call of the ST-library as a critical region.
Thus while YOU may not care about MT, you should strive to make all your code reentrant at the very least. To whatever degree this allows contention-free memory access (e.g. ZERO global variables). This future proofs your code.
Use modern inversion-of-control programming models - don't own your dependencies, but instead require factories for the objects you actually need. You read-only value-objects where-possible, factory-IOC singletons where possible, stack-based allocation, minimal co-mingled data-structures. If you have the ability to leverage Garbage collection, do so for co-mingled structures (or maybe explicit reference counting).
This may actually slow your library down and grow it's size slightly.. But you'll have less coupled / more modular code, which can't be a bad thing. And you'll be more likely to be MT-safe out of the box.
Then if tomorrow you find you can parallelize some aspect (possibly by using message-passing worker threads), or that some 3rd party can do so TO your work, you'll get performance for free.
While you're correct from a temporarily practical measure, I disagree in theory. OS theory 20 or more years ago was about one very simple concept.. Keeping all resources utilized. Instead of buying 20 cheap, slow full systems (at a meager $6k each), you can buy 1 $50k machine and time-share it. All your disk-IO will be maximized, all your CPUs will be maximized, network etc. Any given person is running slower, but you're saving money overall.
If I have a single 8 core machine but it's attached to a netapp disk-array of 100 platters over a network, then the latency means that the round trip of a single-threaded program is almost guaranteed to leave platters idle. If, instead I split a problem up into multiple threads / processes (or use async-IO concepts), then each thread can schedule IO and immediately react to IO-completion, thereby turning around and requesting the next random disk block. While async-IO removes the advantage of multiple CPUs, it's MASSIVELY error-prone programming compared to blocking parallel threads/processes.
A given configuration will have it's own practical maximum and over-saturation point. And for most disk/network sub-systems, 8 cores TODAY is sufficient. But with appropriate NUMA supported motherboards and cache coherence isolation, it's possible that a thousand-thread application-suite could leverage more than 8 cores efficiently. But I've regularly over-committed 8 core machine farms with 3 to 5 thousand threads and never had responsiveness issues (each thread group (client application) were predominantly IO bound). Here, higher numbers of CPUs allows fewer CPU transfers during rare periods of competing hot CPU sections. If I have 6 hot threads on 4 cores, the CPU context switches leach a measureable amount of user-time. But by going hyper-threading (e.g. doubling the number of context registers), we can reduce the overhead slightly.
Now for HPC, where you have a single problem you're trying to solve quickly/cheaply - I'll admit it's hard to scale up. Cache contention KILLS performance - bringing critical region execution to near DRAM speeds. And unless you have MOESI, even non-contentious shared memory regions run at BUS speeds. You really need copy-on-write and message passing. Of course, not every problem is efficient with copy-on-write algorithms (i.e. sorting), so YMMV. But this, too was an advocation for over-committing.. Meaning while YOUR problem doesn't divide. You can take the hardware farm and run two separate problems on it. It'll run somewhat slower, but you get nearly double your money's worth in the hardware - lowering costs, and thus reducing the barrier to entry to TRY and solve hard problems with compute farms.
amazon EC anyone?
Do you debug and maintain 'cd'ing directories? How about opening a log file with a text editor? How about debugging your excel file? Why not? Because the input and output are reproducable and they are one-time events. If I'm trying to ask the question - how many log files did this application just produce.. I can
A) open up a stupid gui and manually count them (if I'm lucky, I can sort by extension - but good luck if they're spanning multiple directories)
B) I can do a file-system search for *.log files, and manually count them.
C) Write a one-liner such as:
find -name '*.log' | wc -l
Now if I wanted to add up their file sizes:
find -name '*.log' | xargs ls -l | awk ' { $sum += $F[5] } END {print $sum} '
This is the basis of shell programming - BUT when you start adding conditional, it becomes very unnatural
for x in $(find -name '*.log'); do [[ -f $x ]] && echo "Found $x"; done
Nothing there denoted the 'if statement'. Enter perl. The ability to run all these shell-like commands, AND leverage all of 'awk' and 'sed's text-processing powers, AND have a full blown turing complete language.
Go through 4 more revisions and you create the one-time glue of the internet.
Perl is a very natural language if you're use to sh, bash, sed, awk, grep and friends. It looks foreign to windows people because batch files have equally bad syntax. And of course straight-programmers that have never had to script in their lives look down on such languages as beneath them I'm sure - much like menial labor.
who said sub-atomic? I said differential equations.. EE 301 type course..Simple circuit modeling equations. It's not precise, but it gives you appropriate steady-state and transition probability equations between coupled modules or within modules..