A more general statement that I think encompasses what you are saying is that fear makes us more reactive, tense, quick, and often times more aggressive. Aggression can be viewed as the cat stuck in the corner.. Fight or flight.. What makes this quickness valuable biologically and politically is that the game of chess is no longer manageable. If your enemy thinks they can reduce your options, and trigger a specific response from you which you are more than prepared (e.g. force you to play into their hands), then fear CAN trigger a seemingly random response which can A) throw the opponent off guard B) keep the pace of the game going faster than they can compensate.
Unfortunately the typical response is to strike back, which means that more than likely, you're playing into their hands. But, your flinching example was a perfect example of the randomness factor - being a much harder target to hit.
www.springframework.org is a must - there is over a year's worth of learning in this suite of libraries. This, more than any library affects good coding practices. It's an outright replacement for EJB. It successfully implements AOP but few of the negatives. You just get more work done while simultaneously future-proofing your code.
jakarta.apache.org - there's a year's worth of learning in these libraries. commons-logging, commons-beanutils, commons-digester, commons-codec, commons-dbcp are just a few of the invaluable libraries.
hibernate.org - This will take a long time to MASTER. There are tons of bugs and use-cases that it just handles poorly. But this plus a mix of either raw JDBC (which I don't recommend) or spring's JdbcTemplate provide for a very elegent combination of DB accessibility. The biggest advantage of hibernate, in my opinion is that you can break the problem down into a series of layers, and work on each layer independently. Caching, delete-cascades, object-oriented design, filtering, event-processing, message-pasing, static-queries and OOP-queries.
http://www.opensymphony.com/quartz/ - I'm not crazy about quartz - it doesn't do things the way I'd like. But it's one of the better scheduling systems for Java enterprise.
tomcat and or jboss and or glassfish are a must. You're not very useful without a FULL understanding of how to setup (and this means clustering, fail-over, session-replication, session-server-pinning, apache-front-ending (to support server-pinning and static-file off-loading)). Learning mod_jk (which I hate in many-to-many server-to-application configurations) AND Apache 2.2's mod_proxy_http (which I love). Learn everything there is to know about deployment. How files get stale.. Where different log files end up. How to configure logging on the fly.
Learn Java's JMX, to better understand how to work with long-running java processes. Jboss makes it easy, and tomcat makes it available.
Learn Eclipse or other major editors (can't vouch for netbeans but I hear a lot of good things). IntelliJ's IDEA is a great (but expensive) commercial editor. This is what really differentiates Java from other languages. There is almost nothing in the language that can't be analyzed by the editor. Since Java is strict (except for reflection), it is very safe to do multi-thousand-file variable/method/class renames, safe-deletes, etc. With annotations, most of the meta-programming has started going away - meaning some things we use to treat reflectively directly in code are now handled by 3'rd party tool-kits which have you place annotations in your code to mean special code-flows. The advantage is that if your editor is aware of those 3'rd party tool-kits, then it too can analyze your code for those annotations.. Hibernate 3.3 is a great example. My editor checks DB column names, types, constraints in real-time based on the annotations. It can investigate the HQL (Hibernate Query Language) and spell-check column names - purely based on these higher-level annotations. All you need is an active community to keep such 'magic coding syle's well understood by the popular editors.
Definitely learn DB transactions inside and out.. Learn how to avoid race-conditions. How to avoid dead-locks. How to perform optimistic locking, how and why that's different from pessimistic locking (this isn't a java thing, it's an enterprise DB thing). This does require postgres or INNODB in mysql instead of MyISAM, however. Learn how to write code which has as few inter-dependencies as possible, to support high volume concurrent programming.
Learn to program with as little static (global) variables as possible. Learn how mentally identify regular non-static fields as globals. Namely if two threads can see the same field, it's a global - plain and simple. Learn how to code to MINIMIZE synchronization constructions - this minimizes dead-locks, and speeds up code. Note a dead-lock is a bug in you're code; just
Being an enterprise multi-threaded programmer, I'm going to beg to differ.. The reason being that people THINK single-threaded when they program - I know because I've had to retrain lots of entry-level programmers who give little/no thought to race-conditions, synchronized routines.
But also in this MT environment, there is a LOT that a trivial text-editor can be doing in the background.. The more complex the task you are performing, the more real-time analyzers can be thought up by trivial-editor writers.
Take MS word.. You have grammer checking, but what about background googling to do FACT checking. In programming, we have control-space or in bash we have tab 'completion'. This is all easy enough to do in a single-thread, but what if the data isn't deterministic? What if it's contextually relevant. Then having a background thread do deep seated analysis after every keystroke make the completion operation more than just 'redo this thing I told you to remember', but it's a litteral co-pilot, where you can trust that you can give a task to some separate mind to make a small decision for you - one that is submitted for your approval.
This is a VERY complex task, and is obviously highly sensitive to the nature of your work. But story writing, formal documentation, technical specifications, functional specifications, test-plans, business plans, excel data-analsys, emailing. To say nothing of programming.
I have 4 gig of memory and the fastest, widest number of CPUs I can get my hands on, and that's MOSTlY because of my trivial text-editor (for which I often fall back out to vim if I'm remote, or gedit/kompare). And I do ZERO graphics work.
Tools are limited only by our imaginations. AI will never take off if people don't harness their abilities, in small practical everyday ways.
How does knowing my mother's maiden name help anybody, if it is never used by me for biometric profiling? I'm not talking about only giving my real info to banks, I'm talking about lieing to banks as well.
So far, the only obsticle I've run across are services that do credit-history lookups - they'll give multiple-choice from random items in that list.. I agree that THAT info is googleable and thus completely insecure.. Only way to avoid that is to sue those type of companies.
Oh, an addendum. Government backdoors are bad NOT because the NSA is snooping, but because the idiots that designed them probably left the keys somewhere where the Russian mafia can find it. So now the people that I most want to keep away from my private data are tunneling through US government backdoors - way to protect and server bozos!
I'm not joking about this, Eastern European hackers are very well practiced, and the Eastern Mafia are very well organized. Or at least that's why I mumble to myself repeatedly when I put on my tin-hat. Kidding aside, I had several room-mates in college from other countries, of varying degrees of repute, and these were the war-stories passed over a couple too many beers.
ssh to a central trusted system with a custom encryption solution such that viruses would not be able to generically detect useful info. I don't trust traditional keystore systems because: A) I don't know if there are government back doors B) well crafted attacks can search for them like viruses that search for quicken files, or root-kits that replace specific binaries) C) You can lose your portable USB stick and any hacker worth his salt would run crack on any encrypted files found on such devices.
This does mean that if the central system looses internet connectivity or power, I'm restricted to whatever my remote browsers stored-passwords have cached. But this has rarely been a problem in the past 10 years, and almost never been critical.
Huh? I'm talking about the hundreds of public web sites that ask the same questions as my bank does. And if THEY are hacked (or have disgruntled managers), people can brute-force my bank with the forgot-password link's profile-info.
My comment about the PIN is that it stands the reason I'm not going to reuse a bank PIN on some public web site, so such an attack is not as useful or even possible.
For every web site that asks for a password I randomly generate one.
If they have the audacity to ask for personal information, I randomly generate that data too. What frustrates me is that now I have to store a series of name-value pairs - because some of these web sites insist on randomly asking me to confirm my identity on occasion with these profile questions.
What frustrates me even more is that most people are stupid enough to give random / anonymous web sites such personal info.. What if one of the questions was 'what is your VIN? What's your SSN'??? Would people ignorantly post that data too??
If the website requires a credit card, use this information for credentialling. If it's a community web site, use email responses - if the email is hijacked, the owner should be able to see the flood of change-password emails. I never understood the value-add of such personal-info bio-metric questions.
My bank uses a PIN in additional to the login. This actually makes sense to me - as PINs are generally easier to remember than my 10 digits random char-lists, but moreover it's at least honest about the purpose of these extra fields - and doesn't dupe people into leaving their pants down when the DB gets hacked one day.
Would be pretty dangerous to allow a process to grab random executable processes and set debug statements in them without in some fashion endangering the user.
Course in UNIX, we've just always assumed that the user was smart - and if they do all their compiling/debugging as root, they'll only take their sad little company with them.
But to your point, the philosophy of UAC requires some consistency, otherwise it's useless.. Either you flag dangerous service calls with user-intervention, or you have some other organization for dangerous apps.. My dad runs zone-alarm and it prompts him on just about every freaking outbound net-access. I think the only practical knowledge that comes out of that experience is a 'don't notify me about this particular app again' checkbox.
We should bring the casual user back to the cartraige / CD / locked-down box concept.. Say, we don't trust you to customize your box. Get certified or buy a more expensive version if you do.
Most OS's provide sufficient hooks to allow the user-space to request peer process memory-segments be addressable, manipulateable. Think debug, kill-signals, core-dump, strace, etc. I don't know the windows equivalent, but I'm sure they're there too.
Doesn't do much for a server infiltration, but with a dedicted user on a PC, it's more than ample for the needs of a virus.
I don't think you need to break into kernel mode. All you need is to run at the most privledged user-level that the OS allows (I'm not an MS internals guy, so I'm speaking genericly). You SHOULD be able to 'request' that the kernel does all your dirty deeds for you.. Of course a good kernel won't let you touch things it doesn't think you own.. But consider that 99% of PCs out there have a single owner.. What possible segments of the computer wouldn't be disasterously affected by the one-and-only user on the system?
For example, you can obviously open pretty much any non-kernel file. You can edit the user-specific registry settings (which can pretty much load whatever services you desire at next bootup). You can make TCP calls galore (probably can't get ethernet snooping levels thankfully). You can probably 'attach' to any running process owned by the same user. Thus you can grab outlook, outlook express.. Any web browser. Install key-stroke recording, etc.
Being able to inject arbitrary binary executeable code is much nastier on windows because 90% of the files are writeable by the user. Maybe it's less these days, but I doubt it.
I would compare your perspective of 'alive' to that of Right wing perspective of 'marriage'. Pressing a specific definition for the sake of retaining the implications of that definition.
Others have pointed out that we're having the same problem with the definition of a planet.. And I hope the officials focusing on refining it's term can sleep well at night. The particulars are almost meaningless anymore.
The fact of the matter is that new information about our world requires that we re-asses how we classify things, how we label things. Often we categorize things some way for centuries, then find that it's actually counter-productive to continue the classification that way.
If you believe in a permanent Soul, then maybe the categorization of alive v.s. inanimate is important. More importantly, if you believe the 'killing' of something has human importance (e.g. melting crystals v.s. boiling bacteria v.s. cooking a cat), then the categorization may have significance.
For my part (for what it's worth), the first time I had to seriously consider 'life' was in a high school biology course.. And the teacher initiated the subject by having our class 'try' and define it. I don't think there were two people that were even close to each other. My personal attempt was that there exists a series of attributes (and I listed 8 or so) that are non-exclusive and non-manditory such that, the more there are, the more appropriate the word 'life' applies.
These days, I am a big believer in the statistical distribution of facts and reality.. I believe (lazy hypothesis) that all possible combinations of atomic (and non-atomic) organizations of energy exist, or should exist. That there are no discontinuous realms of existence - finite/quantized as energy and the universe may seem to be. That for any insurmountable, impenetrable barrier of existence, there exists some combination/orientation/coupled-effective-existence that fills in the gap.. Thus from this (unsubstantiated) perspective, there should be a continuous transition from the simplest form of energy to the most complex... Thereby there should be little or no clear transition from alive to lifelessness. There should be a complete suite of probable particle/energy combinations that go from simple amorphic solids to highly regular crystals to highly organized protiens to highly complex cellular machinery and on up..
My main reasoning is we have historically found continuously smaller, larger and gap-filled regions of knowledge.. There is no reason to believe that remaining gaps will not eventually be filled, especially as the rate of gap-filling only seems to increase. There are two possible conclusions, there is a grand quantized/gap-filled pattern and we're very far from seeing it clearly, so the rate of discovery is natural only for certain sections of this grand equation.. Or there really is a continuous distribution of energy, organization and existence - but our discovery of the gaps is accelerated/slowed based on unevenly distributed evidence.
Sorry for 10,000 foot from-science discussion - it's been a long day.:)
We always use to HATE VCR recordings. There is something about a live teacher that keeps you awake.. She looks you in the eye every 30 seconds giving you a feedback system of personal responsibility. You know if you doze off you'll get called on for a random thing - just to keep your attention span up. How do you accomplish this with multi-cast? Consider the 8-3 as one long meeting 5 days a week, for 12 years straight - extremely draining unless you have constant human interaction - which is what the teacher provides.
As for learning at your own rate. This only works when the student has demonstrated self-motivation. Montesouri schools are predicated around the fact that some things can be intrinsically self-taught. The art of discovering class materials that accomplish this is no easy task though.
I'll completely agree about disruptive students.. But this includes hot girls. I can't quantify how many class hours were lost dazing across the room at the back of some gorgeous leg.
Yes, and the corruption that produces charter schools with nothing more than a compelling business plan, would leave about 5 years of stolen money from the public school system. Roughly the amount of time before local governments could prove several of the recently created local charter schools were either scams or hyper-mismanaged.
This isn't a take against charter/private schools, it's a take against a MASSIVE slosh of funding thrown towards a specific target with lots of creative minds in a capitalist society.
If you accept that competition will produce a more 'efficient' school system, then you have to accept that it does so by weeding out cancerous schools. New ideas means some REALLY bad ideas will exist in the market place for a long while.. The difference is that the experiments will be unsuspecting generations of school children.
I also guarantee that a voucher system would have a massive uptake in church schooling.. And we've never seen a Christian denomination produce scandelous steal-from-the-poor mega-churches have we? Didn't we just shut down the Taliban? Do we really need to reproduce it here? God only, science-is-from-the-devil, questioning-faith-sends-your-soul-to-hell schooling.. wonderful.. Not saying church schools don't work (Catholic schools do quite well, thank you). But in this fly-by-night churching society we have, it's guaranteed that some poor town will set up a horribly underqualified, backwards church-school, with the promise of tons of government money. Only takes 2,000 bad apples to spoil the barrel. And we've got a full 2/3 of a country full of barrel hunters.
My parents went to Catholic school, and I went to public school, and I never had a problem with their systems. My family is very well educated as a result. But my parents and myself had strict homework encouragement in our respective families. Many of my friends who never made it very far from high-school were sega-mongers afterschool with mostly absent parents (at least while we were at their houses). School was free day-care for their 14-year-olds as best I could tell.
I don't know how much public education has changed since I've been there, but I recall it as being very systematic. There was little confusion about course materials - only people that hadn't done their homework and progressively fell further behind. Classes always had feedback systems. Very rarely did we see multiple choice - most quizes involved critical thinking - no guesswork possible. Partial credit was assumed. I was actually surprised when I got to college and the proliferation of multiple choice. The D-average was possible practically by guessing and showing up to class every day. I understand the challenges of 100 students per teacher in college necessitating less critically reviewed quizes/exams, but I honestly think I got a better education (fact for fact) in public elementary and high school than I did in college. And I went to a well-ranked college.
High school was what you made of it.. I was highly motivated and had a powerful support structure at home. But by sophmore year I'd surpassed the ability of my parents to help with homework, so the only thing you can argue at that point is positive re-inforcement. I was (as many slashdotters, I'm sure) an introvert so I didn't have the daily distraction of socializing - which I fear represented my main advantage over my high school competition. The sense of excelling I'm sure was a prime motivator in and of itself (as a sports athelete is driven to rise from 3'rd place to 2'nd or maybe even first). If we had school uniforms, greater anti-social regulations in classes, I'm sure that my competition would have been much firmer and I'd have been less motivated as a result. Who knows. I will say that parents have a tremendous influence on how their children develop self-esteem. If you're told you have to make friends, doing x,y,z will make you popular or cool, funny, the life-of-the-party. If doing things (as a parent) to help your kid look cool or s
Jumping in the middle of the thread - his reasoning is not stupid. It says there is a cost to adding a layer (band-aid) which can plausibly have other side effects.
If there is a known event that produces a plausibly known negative outcome, any action that attempts to mitigate the outcome without directly addressing the source is, at best, managed chaos.
Yes, Humans have gotten very good at this, but only when we have an extremely high degree of confidence of all the possible parameters. The parent is expressing the fact that we do NOT have such knowledge of cause-and-effects with respect to changing the chemical distributions of our highly complex oceans (it's only the cradle of life for God's sake).
Because the central government doesn't collect sales taxes, only the local governments. And in many states, there are lots of businesses near state borders (NYC, DC, Philly, Las Vegas, Las Angeles, etc). As a local mayor (or governor), you want your local prices to 'seem' as low as possible so you can solicit money from adjoining towns/cities. The best way to do this is to have advertised prices 'seem' lower.
A local shop knows that idiots round down the cents.. So $99.99 is "under a hundred". Likewise morons think $4.09.99 for gas is really $4.09 (because the sub-sub number is really really small on billboards). Psychologically given two vendors within eye-shot of each other, the one advertising $100 is going to lose business to the $99.99 billboard.. Technically it is cheaper, but if you happen to be down-road, it obviously won't even pay for the extra gas.. But the psychology is that 'other stuff might be cheaper too', and 'every little bit counts', 'A penny saved, is a penny earned' (truer when people actually 'made' pennys / hour)
If you include taxes, the $9.99 becomes $10.48.95 at 5% (typical state sales tax). Which means the vendor needs to charge below $9.49 to avoid "sticker shock" of 1/100th of a penny. A 50 cent loss to the vendor. Since MOST goods advertised at $x.99 are really between $1 and $10, this is actually a very large percentage. $0.99 becomes $0.94 (5.05% loss in revenue). And that's only for 5% taxes.. 10% taxes (DC and other touristy places) would equate to heaftier losses.
Again, this is the very real, provable and scientific proposal that idiots (defined as 99% of us) make buy-or-fly choices based on exceeding or avoiding nice round numbers.
As condescending as I might sound, I personally succumb to the relative discount phenomena. If you go to a restaurant where they show $60 steak on the menu, the $20 pasta and $5 glass of water looks like a bargain. Course I only eat out twice / year.
* no flicker * INSTANT on * INSTANT max-brigtness * 5W v.s. 16W for a 700lumen bulb replacement LED v.s. CFL - efficiencies scale better for LED than CFL for lower lumans, but benefit CFL for higher lumans. * lighter * more durable * no mercury * longer life expectancy
The two negatives are the color spectrum and price of LEDs. You can get very nice ranges of colors in CFL's these days (soft, white, 'natural daylight'). The few LED lights I've sampled have very distinct colors.
CFL's are already cheaper than incandecents even if you ignore energy costs (due to 1/4 to 1/10th the replacement schedule). LEDs advertise 6x the life of CFLs. While I'm aware of CFL's not all being equal - cheaper brands get 70% of their advertised life, while many name-brands get 120% of their ratings. LEDs haven't had anywhere near the public testing (because there aren't enough volume vendors to test against).
I read all the wiki had to offer. I agree that this is a problem - I'm going to see if I can post to their complaint forum as well.
Basically you have a URL that contains 4 pieces of information.. A file name (largely meaningless except to the end user), a file-size, and 3 30-Byte SHA-1 hashes, referred to here as a 3-tuple (represented in HEX). You search the local disk cache for file names that match each of the SHA-1 digests. For every digest file not found, search the local network for a match and download the block locally (this is the peer-to-peer part).
You XOR the contents of the 3 blocks (which happen to be sized at 128K - no significance) to produce the decoded data.
The first decoded block (provided from the URL) is a sequential-list of 90 byte 3-tuples (similar to the original URL). The contents of all of these 3-tuples are the desired data, except the last 3-tuple which is a chain to the next descriptor block.
The file-size tells you when to stop obviously.
The 'theory' is that highly randomized data should be randomly reused by completely unrelated data...mp3 and.txt files, for example. Moreover, there is 'no way to reconstruct' useful data w/o the 3-tuple AND the file-size. However, small files will have a high probability of SHA-1 collisions (and thus corrupted data - they only talk about virus corruption, but there's the more important inadvertant collsions which overwrite valid data - BackupPC resolves this by creating MD5;1 MD5;2 file-names). The large 128K should alleviate this, but also assures a low probability of block reuse.
The problem I see is that data-blocks are not inherently random by default.. In order to be practically random, you'd have to take the recommended 1TB file-system, randomize it - produce approx 8 million SHA-1 digests, then for each real-data insert, delete in an LRU fashion. Otherwise, if you only had a hundred-thousand blocks - It would not be THAT difficult to grab the first 30 bytes of every block and XOR them with several of the most recently inserted blocks until you found something that matched an existing file-name. If matched, try the next 30B, etc. Now you have a starting point AND the appropriate 3-tuple. You're only missing the file-size.. But if it spits out music in one of like 5 codecs, you've got a winner. Shouldn't be able to do statistical analysis to find random-noise or invalid media format. Many files contain internal end-of-file signifiers (.zip,.gz for example).
With 8 million records, that becomes hard(er) to do. But how long does it take to initialize that?
Now with respect to the network, there's no need to actually store the file-descriptor block remotely, Thus for highly sensitive files, you can probably encrypt the descriptor block and keep it locally (sharing on a private trusted network). But for text-based files, you'd probably still be weary of having network stored timestamp ordered data-blocks - as the contents of the last 100 blocks could easily be determined, (text files are not as order sensitive as mp3s and zip files).
The stated goal is purely open, freely shared, perfectly legal data-store... Which allows the occasionally masked sensitive data. Though the RIAA/MPAA would read it as, a front for illegal data.
They say they have better bandwith than obscured P2P networks, since you can allow open download by the RIAA as well as your clients, and it's all meaningless w/o the starting points/blocks. You do have a 3x bandwidth over a pure HTTP/FTP download - as you have to download 3 blocks to XOR against each other to produce 1 block of data. They suggest that once you have a descriptor block you 'should download the tuples in random order to reduce pattern matching by ISPs' which furthers the notion that this is for illicit purpose.
I'm highly suspicious that the SHA-1 digests produce useful collisions and provide you bandwidth reduction via your local disk-cache for the above comments.
General rules: 1) Unrelated code should not be capable of interfering with each other (liberal use of unique package-name-spaces)
2) Load order should not affect the outcome of the application (php/jsp/javascript include-files)
3) Transient data should naturally expire (block-scope or ref-counting or garbage-collection)
4) Side effect programming should be avoidable.
5) Where possible, data should be immuteable (a specialization of item 4)
6) Where possible, code should reflect hierarchical abstractions, where the least amount of information is needed to follow or use a code snippet (this encompases data-hiding, procedures/functions with minimal input parameters, function-names / variable-names that naturally match the intended execution).
7) Code (the language) should be expressive and concise. You should be able to do a powerful thing with a few lines of code. A regular expression, a SQL statement, a lex/flex BNF-form expression, a prolog-rule. These are well-thought-out highly capable and flexible sub-languages. To whatever degree your code can leverage multiple languages (presumably by leveraging libraries that interpret syntax differently at different sections of your code), your code will have fewer bugs, be easier to make small changes that have radically different outcomes, and be easier to read - At the expense of more training time for new coders.
8) A language should be a building block, such that coders do not need to start from scratch - but instead search for the module/capability, and instead of coding, you are 'wiring' the 3'rd party library to act as you intend. This is as much a social issue as a language issue. If a language has a single repository / standard, it's easier for this social dynamic to occur. If, like C, most vendors do not play well with one another, you will be hard pressed to expand on a repurposeable building block.
9) Code should lend itself to run-time analysis. Debugable, steppable, stack-traceable, efficient and run-time configureable log-file emmission (log4j and friends is a nice framework), live thread-execution analysis (with little or no obstruction), memory allocation analysis (histograms of data-types, both count and size).
10) Code should be unit-testable. This isn't as easy as it sounds.. This means all references to dates and other OS resources need to be abstracted such that a unit-test can mock an OS resource. This also means the setup of a code resource (beit a class instance or the setup of global variables (ick)) should be sufficiently simple that the unit-test does not need to test the configuration aspect of the code; just the code itself. Note that unit tests don't necessarily need to have 100% code-coverage (as many philosophies dictate), BUT when there is a production-environment issue that needs resolution, the ability to divide-and-conquer the problem by QUICKLY throwing together specific unit-tests is indescribably valuable. Code that is not designed with the idea that it MIGHT be unit-tested is almost impossible to do this with. Languages that facilitate unit-testing are also invaluable.
11) Naming conventions should be consistent within a project.. And ideally across the language. XXImpl, XXBean, xx getXxx(), setXxx(xx), XXFactory, XXAdaptor, XXReader, XXWriter, XXController, XXDAO, etc, reduces the learning curve for any API.
12) Inputs and Outputs of any function/procedure must be absolutely clear.. If you're sadly using a language that requires 30 input parameters for a procedure/function, and the language doesn't have sensible defaulting capabilities (overloading or default field parameters) then A) shoot-yourself B) write an adaptor which minimizes the inputs. Create XXAdaptor adaptor code with setXX(x) and xx run(); that uses appropriate/sensible defaults.. This should work for most any language.
13) Reduce the impedance mismatch between unrelated code. A standard imposed by the language (InputStream, OutputStream, Runnable, Method, Reader, Writer, Co
Believe me, I prefer message passing system. I'm not knocking them in any way. When given the chance, I reorganize code into stateless (rather self-contained, context-free) serializable messages - in the case that they might need to one day transport onto an alternate clustered node.
However, I've recently had to deal with a problem that required a massive in-memory priority heap (hundred million DB records with 100k in-mem group/category descriptors). The best you could do is partition the data-set across multiple clustered nodes then write in synchronization routines which guarantee you're pulling the next highest priority item (either from a local node or a remote node).. But in our case the working set could fit in memory, and clustering would have been a lot of extra potential for bugs - far outweighing the probability of race-condition bugs (which are far worse than dead-locks, because they're silent but deadly).
A pure DB solution was deemed far too slow for many common mass-data manipulation events. Not to mention the transient nature of the priorities.
In this case, a trivial fail-over detection with a semi-idle slave node was sufficient. Semi-idle in the sense that there were truely clusterable activities that occurred on the same hardware (namely the real-time responses to the prioritized messages).
Message passing systems and MT systems solve different problems. Consider that Message Passing is a subclass of Multi-Processing; in general the amount of work is much larger than the data-set. But Multi-Threading often involves many micro-changes to a large message (the entire state of the process).
Consider an in-memory database. (Mysql-cluster (NDB), for example). You wouldn't want to pass the entire database around (or even portions of it around) for each 'job'. Instead, you'd like at most only partitions of the data where massive working-sets reside on each partition and do inter-data operations. Then your message passing is limited to only interactions that aren't held in the local memory space (i.e. NUMA).
With Terracotta you are breaking a sequential application into a series of behind-the-scenes messages which go from clustered node to clustered node as necessary (I'm not very well versed on this product, but I've reviewed it a couple times).
Thus for certain problems that do not nicely break down into small messages, you are indeed limited to single-memory-space hardware. And thus, the more CPUs (that leverage MESI (sp?) CPU cache) the more efficient the overall architecture.
Now, I can't imagine that a 768CPU monster is that cost effective - you're problem space is probably pretty limited. But a simultaneous 700 thread application is NOT hard to write in java at all. I regularly create systems that have between 1,000 and 2,000 semi-active threads. But I try to keep a CPU-intensive pool down to near the number of physical CPUs (4, 8 or 16 as the case may be). Java has tons of tools to allow execution-pools of configureable size.
Correction. The Big 5 US carriers facilitate 160 physical characters per chargeable SMS message. Some carriers have overhead that reduces this somewhat, and message concatenation consumes 7 to 10 character slots(8-bit bytes if you prefer).
I also like how people are quoting under 15 cents per message (sending AND receiving). Have you checked your bills lately?
The real rip-off however is not SMS, but MMS (at $1.50 each).
Consider that if you've ever done UNIX programming, you've been doing MT programming all along - just by a different name.. Multi-Processing. Pipelines are, in IMO the best implementation of parallel programming (and UNIX is FULL of pipes). You take a problem and break it up into wholly independent stages, then multi process or multi-thread the stages. If you can split the problem up using message-passing then you can farm the work out to decoupled processes on remote machines, and you get farming / clustering. Once you have the problem truely clustered, then multi-threading is just a cheaper implementation of multi-processing (less overhead per worker, less number of physical CPUs, etc).
This is a 7 process FULLY parallel pipeline (meaning non-blocking at any stage - every 512 bytes of data passed from one stage to the next gets processed immediately). This can work with 2 physical machines that have 4 processing units each, for a total of 8 parallel threads of execution.
Granted, it's hard to construct a UNIX pipe that doesn't block.. The following variation blocks on the xargs, and has less overhead than separate tar/compress stages but is single-threaded
Here the message-passing are serialized/linearized data.. But that's the power of UNIX.
In CORBA/COM/GNORBA/Java-RMI/c-RPC/SOAP/HTTP-REST/ODBC, your messages are 'remoteable' function calls, which serialize complex parameters; much more advanced than a single serial pipe/file-handle. They also allow synchronous returns. These methodologies inherently have 'waiting' worker threads.. So it goes without saying that you're programming in an MT environment.
This class of Remote-Procedure-Calls is mostly for centralization of code or central-synchronization. You can't block on a CPU mutex that's on another physically separate machine.. But if your RPC to a central machine with a single variable mutex then you can.. DB locks are probably more common these days, but it's the exact same concept - remote calls to a central locking service.
Another benifit in this class of IPC (Inter Process Communication) is that a stage or segment of the problem is handled on one machine.. BUt a pool of workers exists on each machine.. So while one machine is blocking, waiting for a peer to complete a unit of work, there are other workers completing their stage.. At any given time on every given CPU there is a mixture of pending and processing threads. So while a single task isn't completed any faster, a collection of tasks takes full advantage of every CPU and physical machine in the pool.
The above RPC type models involve explicit division of labor. Another class are true opaque messages.. JMS, and even UNIX's 'ipcs' Message Queues. In Java it's JMS. The idea is that you have the same workers as before, but instead of having specific UNIQUE RPC URI's (addresses), you have a common messaging pool with a suite of message-types and message-queue-names. You then have pools of workers that can live ANYWHERE which listen to their queues and handle an array of types of pre-defined messages (defined by the application designer). So now you can have dozens or hundreds of CPUs, threads, machines all symmetriclly passing asynchronous messages back and forth.
To my knowledge, this is the most scaleable type of problem.. You can take most procedural problems and break them up into stages, then define a message-type as the explicit name of each stage, then divide up the types amongst different queues (which would allow partitioning/grouping of computational resources), then receive-message/process-message/forward-or-reply-message. So long as the amount of work far exceeds the overhead of message passing, you can very nicely scale with the amount of hardware you can throw at the problem.
What does javascript and java syntax have to do with one another? Javascript is closer to VB-Script, which I still convulse when I remember my prison days of working with. I only like loosely typed / late-binding language for rapid prototyping languages. Python, perl, bash, javascript, awk. But I don't like the negatives with that late-binding when it comes to advanced middleware. The code-base is far too fragile, and you don't get a whole lot of code-reduction in the syntax (to your point of verbosity).
Now SQL, ruby, and prologue are three radically different syntaxes which I find some beauty in. But to me Java, C, C++ are all VERY similar (by design). While java has statistically more characters in a given bundle of code, it has a far superior compilation framework (don't need to compile 5 meg of.h files for every 5 line.c file), and is structurally identical to C++; a mixture of procedural and OO coding. Contrast this with a functional language which, for a given domain, can be far superior in term of visual clarity of the presented code.
Every language has it's niche, and the further you deviate from that niche, the more you stick out like a sore thumb.
You (as well as many) are focusing on the verbosity of the language. But there are sufficient tools which mitigate the verbiage of java. I, on the other hand, am focusing on the feeling I get when I'm programming in the language (kind of like dating the language). Am I frustrated by things that I feel we shouldn't be worrying about in the 21'st century? How robust is my peer's code? How packageable/encapsulateable is it? Can the language constrain his deficiencies? In C, no. In C++, maybe a little better. In javascript, no. In perl, you'd have to do something weird (like flip package spaces). In Java, definitely. So this amongst dozens of other nuances, makes the language feel more elegant and pleasurable to work in.
Consider documentation. In perl, there is sufficient magic to keep a single person employed for a long time. In javascript, documentation is often only at the highest level (here, use this example). In C, lord help you - you had best pray the documentation has been kept up to date. In Java, you don't even need documentation - the strictness of the language allows you to dynamically ascertain all possible calling conventions (with the possible exception of a 10 integer static function where you don't know which parameter means which - but in my experience, most 3'rd party functions have only one or two parameters). There is no code you can link against in java that you can't [auto]discover it's intended interface.. And the verbosity of the language is self-documenting. public class MyOptimizedXmlFactory { public static XmlReader createReader(File){} } is kind of hard to mis-interpret. In fact, the language is so well structured, that javadoc can build an entire web site from literally any existing code that defines every possible useage pattern (except for unnamed parameters as described before - though well documented code will properly annotate the parameter useage).
Slashdot Mirror
A more general statement that I think encompasses what you are saying is that fear makes us more reactive, tense, quick, and often times more aggressive. Aggression can be viewed as the cat stuck in the corner.. Fight or flight.. What makes this quickness valuable biologically and politically is that the game of chess is no longer manageable. If your enemy thinks they can reduce your options, and trigger a specific response from you which you are more than prepared (e.g. force you to play into their hands), then fear CAN trigger a seemingly random response which can A) throw the opponent off guard B) keep the pace of the game going faster than they can compensate.
Unfortunately the typical response is to strike back, which means that more than likely, you're playing into their hands. But, your flinching example was a perfect example of the randomness factor - being a much harder target to hit.
www.springframework.org is a must - there is over a year's worth of learning in this suite of libraries. This, more than any library affects good coding practices. It's an outright replacement for EJB. It successfully implements AOP but few of the negatives. You just get more work done while simultaneously future-proofing your code.
jakarta.apache.org - there's a year's worth of learning in these libraries. commons-logging, commons-beanutils, commons-digester, commons-codec, commons-dbcp are just a few of the invaluable libraries.
hibernate.org - This will take a long time to MASTER. There are tons of bugs and use-cases that it just handles poorly. But this plus a mix of either raw JDBC (which I don't recommend) or spring's JdbcTemplate provide for a very elegent combination of DB accessibility. The biggest advantage of hibernate, in my opinion is that you can break the problem down into a series of layers, and work on each layer independently. Caching, delete-cascades, object-oriented design, filtering, event-processing, message-pasing, static-queries and OOP-queries.
http://www.opensymphony.com/quartz/ - I'm not crazy about quartz - it doesn't do things the way I'd like. But it's one of the better scheduling systems for Java enterprise.
tomcat and or jboss and or glassfish are a must. You're not very useful without a FULL understanding of how to setup (and this means clustering, fail-over, session-replication, session-server-pinning, apache-front-ending (to support server-pinning and static-file off-loading)). Learning mod_jk (which I hate in many-to-many server-to-application configurations) AND Apache 2.2's mod_proxy_http (which I love). Learn everything there is to know about deployment. How files get stale.. Where different log files end up. How to configure logging on the fly.
Learn Java's JMX, to better understand how to work with long-running java processes. Jboss makes it easy, and tomcat makes it available.
Learn Eclipse or other major editors (can't vouch for netbeans but I hear a lot of good things). IntelliJ's IDEA is a great (but expensive) commercial editor. This is what really differentiates Java from other languages. There is almost nothing in the language that can't be analyzed by the editor. Since Java is strict (except for reflection), it is very safe to do multi-thousand-file variable/method/class renames, safe-deletes, etc. With annotations, most of the meta-programming has started going away - meaning some things we use to treat reflectively directly in code are now handled by 3'rd party tool-kits which have you place annotations in your code to mean special code-flows. The advantage is that if your editor is aware of those 3'rd party tool-kits, then it too can analyze your code for those annotations.. Hibernate 3.3 is a great example. My editor checks DB column names, types, constraints in real-time based on the annotations. It can investigate the HQL (Hibernate Query Language) and spell-check column names - purely based on these higher-level annotations. All you need is an active community to keep such 'magic coding syle's well understood by the popular editors.
Definitely learn DB transactions inside and out.. Learn how to avoid race-conditions. How to avoid dead-locks. How to perform optimistic locking, how and why that's different from pessimistic locking (this isn't a java thing, it's an enterprise DB thing). This does require postgres or INNODB in mysql instead of MyISAM, however. Learn how to write code which has as few inter-dependencies as possible, to support high volume concurrent programming.
Learn to program with as little static (global) variables as possible. Learn how mentally identify regular non-static fields as globals. Namely if two threads can see the same field, it's a global - plain and simple. Learn how to code to MINIMIZE synchronization constructions - this minimizes dead-locks, and speeds up code. Note a dead-lock is a bug in you're code; just
Being an enterprise multi-threaded programmer, I'm going to beg to differ.. The reason being that people THINK single-threaded when they program - I know because I've had to retrain lots of entry-level programmers who give little/no thought to race-conditions, synchronized routines.
But also in this MT environment, there is a LOT that a trivial text-editor can be doing in the background.. The more complex the task you are performing, the more real-time analyzers can be thought up by trivial-editor writers.
Take MS word.. You have grammer checking, but what about background googling to do FACT checking. In programming, we have control-space or in bash we have tab 'completion'. This is all easy enough to do in a single-thread, but what if the data isn't deterministic? What if it's contextually relevant. Then having a background thread do deep seated analysis after every keystroke make the completion operation more than just 'redo this thing I told you to remember', but it's a litteral co-pilot, where you can trust that you can give a task to some separate mind to make a small decision for you - one that is submitted for your approval.
This is a VERY complex task, and is obviously highly sensitive to the nature of your work. But story writing, formal documentation, technical specifications, functional specifications, test-plans, business plans, excel data-analsys, emailing. To say nothing of programming.
I have 4 gig of memory and the fastest, widest number of CPUs I can get my hands on, and that's MOSTlY because of my trivial text-editor (for which I often fall back out to vim if I'm remote, or gedit/kompare). And I do ZERO graphics work.
Tools are limited only by our imaginations. AI will never take off if people don't harness their abilities, in small practical everyday ways.
How does knowing my mother's maiden name help anybody, if it is never used by me for biometric profiling? I'm not talking about only giving my real info to banks, I'm talking about lieing to banks as well.
So far, the only obsticle I've run across are services that do credit-history lookups - they'll give multiple-choice from random items in that list.. I agree that THAT info is googleable and thus completely insecure.. Only way to avoid that is to sue those type of companies.
But if you have a premium credit card service, then you have access to credit-card credentialing / validation; billing-address info, etc.
Oh, an addendum. Government backdoors are bad NOT because the NSA is snooping, but because the idiots that designed them probably left the keys somewhere where the Russian mafia can find it. So now the people that I most want to keep away from my private data are tunneling through US government backdoors - way to protect and server bozos!
I'm not joking about this, Eastern European hackers are very well practiced, and the Eastern Mafia are very well organized. Or at least that's why I mumble to myself repeatedly when I put on my tin-hat. Kidding aside, I had several room-mates in college from other countries, of varying degrees of repute, and these were the war-stories passed over a couple too many beers.
ssh to a central trusted system with a custom encryption solution such that viruses would not be able to generically detect useful info. I don't trust traditional keystore systems because:
A) I don't know if there are government back doors
B) well crafted attacks can search for them like viruses that search for quicken files, or root-kits that replace specific binaries)
C) You can lose your portable USB stick and any hacker worth his salt would run crack on any encrypted files found on such devices.
This does mean that if the central system looses internet connectivity or power, I'm restricted to whatever my remote browsers stored-passwords have cached. But this has rarely been a problem in the past 10 years, and almost never been critical.
Huh? I'm talking about the hundreds of public web sites that ask the same questions as my bank does. And if THEY are hacked (or have disgruntled managers), people can brute-force my bank with the forgot-password link's profile-info.
My comment about the PIN is that it stands the reason I'm not going to reuse a bank PIN on some public web site, so such an attack is not as useful or even possible.
For every web site that asks for a password I randomly generate one.
If they have the audacity to ask for personal information, I randomly generate that data too. What frustrates me is that now I have to store a series of name-value pairs - because some of these web sites insist on randomly asking me to confirm my identity on occasion with these profile questions.
What frustrates me even more is that most people are stupid enough to give random / anonymous web sites such personal info.. What if one of the questions was 'what is your VIN? What's your SSN'??? Would people ignorantly post that data too??
If the website requires a credit card, use this information for credentialling. If it's a community web site, use email responses - if the email is hijacked, the owner should be able to see the flood of change-password emails. I never understood the value-add of such personal-info bio-metric questions.
My bank uses a PIN in additional to the login. This actually makes sense to me - as PINs are generally easier to remember than my 10 digits random char-lists, but moreover it's at least honest about the purpose of these extra fields - and doesn't dupe people into leaving their pants down when the DB gets hacked one day.
Would be pretty dangerous to allow a process to grab random executable processes and set debug statements in them without in some fashion endangering the user.
Course in UNIX, we've just always assumed that the user was smart - and if they do all their compiling/debugging as root, they'll only take their sad little company with them.
But to your point, the philosophy of UAC requires some consistency, otherwise it's useless.. Either you flag dangerous service calls with user-intervention, or you have some other organization for dangerous apps.. My dad runs zone-alarm and it prompts him on just about every freaking outbound net-access. I think the only practical knowledge that comes out of that experience is a 'don't notify me about this particular app again' checkbox.
We should bring the casual user back to the cartraige / CD / locked-down box concept.. Say, we don't trust you to customize your box. Get certified or buy a more expensive version if you do.
Most OS's provide sufficient hooks to allow the user-space to request peer process memory-segments be addressable, manipulateable. Think debug, kill-signals, core-dump, strace, etc. I don't know the windows equivalent, but I'm sure they're there too.
Doesn't do much for a server infiltration, but with a dedicted user on a PC, it's more than ample for the needs of a virus.
I don't think you need to break into kernel mode. All you need is to run at the most privledged user-level that the OS allows (I'm not an MS internals guy, so I'm speaking genericly). You SHOULD be able to 'request' that the kernel does all your dirty deeds for you.. Of course a good kernel won't let you touch things it doesn't think you own.. But consider that 99% of PCs out there have a single owner.. What possible segments of the computer wouldn't be disasterously affected by the one-and-only user on the system?
For example, you can obviously open pretty much any non-kernel file. You can edit the user-specific registry settings (which can pretty much load whatever services you desire at next bootup). You can make TCP calls galore (probably can't get ethernet snooping levels thankfully). You can probably 'attach' to any running process owned by the same user. Thus you can grab outlook, outlook express.. Any web browser. Install key-stroke recording, etc.
Being able to inject arbitrary binary executeable code is much nastier on windows because 90% of the files are writeable by the user. Maybe it's less these days, but I doubt it.
I would compare your perspective of 'alive' to that of Right wing perspective of 'marriage'. Pressing a specific definition for the sake of retaining the implications of that definition.
Others have pointed out that we're having the same problem with the definition of a planet.. And I hope the officials focusing on refining it's term can sleep well at night. The particulars are almost meaningless anymore.
The fact of the matter is that new information about our world requires that we re-asses how we classify things, how we label things. Often we categorize things some way for centuries, then find that it's actually counter-productive to continue the classification that way.
If you believe in a permanent Soul, then maybe the categorization of alive v.s. inanimate is important. More importantly, if you believe the 'killing' of something has human importance (e.g. melting crystals v.s. boiling bacteria v.s. cooking a cat), then the categorization may have significance.
For my part (for what it's worth), the first time I had to seriously consider 'life' was in a high school biology course.. And the teacher initiated the subject by having our class 'try' and define it. I don't think there were two people that were even close to each other. My personal attempt was that there exists a series of attributes (and I listed 8 or so) that are non-exclusive and non-manditory such that, the more there are, the more appropriate the word 'life' applies.
These days, I am a big believer in the statistical distribution of facts and reality.. I believe (lazy hypothesis) that all possible combinations of atomic (and non-atomic) organizations of energy exist, or should exist. That there are no discontinuous realms of existence - finite/quantized as energy and the universe may seem to be. That for any insurmountable, impenetrable barrier of existence, there exists some combination/orientation/coupled-effective-existence that fills in the gap.. Thus from this (unsubstantiated) perspective, there should be a continuous transition from the simplest form of energy to the most complex... Thereby there should be little or no clear transition from alive to lifelessness. There should be a complete suite of probable particle/energy combinations that go from simple amorphic solids to highly regular crystals to highly organized protiens to highly complex cellular machinery and on up..
My main reasoning is we have historically found continuously smaller, larger and gap-filled regions of knowledge.. There is no reason to believe that remaining gaps will not eventually be filled, especially as the rate of gap-filling only seems to increase. There are two possible conclusions, there is a grand quantized/gap-filled pattern and we're very far from seeing it clearly, so the rate of discovery is natural only for certain sections of this grand equation.. Or there really is a continuous distribution of energy, organization and existence - but our discovery of the gaps is accelerated/slowed based on unevenly distributed evidence.
Sorry for 10,000 foot from-science discussion - it's been a long day. :)
We always use to HATE VCR recordings. There is something about a live teacher that keeps you awake.. She looks you in the eye every 30 seconds giving you a feedback system of personal responsibility. You know if you doze off you'll get called on for a random thing - just to keep your attention span up. How do you accomplish this with multi-cast? Consider the 8-3 as one long meeting 5 days a week, for 12 years straight - extremely draining unless you have constant human interaction - which is what the teacher provides.
As for learning at your own rate. This only works when the student has demonstrated self-motivation. Montesouri schools are predicated around the fact that some things can be intrinsically self-taught. The art of discovering class materials that accomplish this is no easy task though.
I'll completely agree about disruptive students.. But this includes hot girls. I can't quantify how many class hours were lost dazing across the room at the back of some gorgeous leg.
Yes, and the corruption that produces charter schools with nothing more than a compelling business plan, would leave about 5 years of stolen money from the public school system. Roughly the amount of time before local governments could prove several of the recently created local charter schools were either scams or hyper-mismanaged.
This isn't a take against charter/private schools, it's a take against a MASSIVE slosh of funding thrown towards a specific target with lots of creative minds in a capitalist society.
If you accept that competition will produce a more 'efficient' school system, then you have to accept that it does so by weeding out cancerous schools. New ideas means some REALLY bad ideas will exist in the market place for a long while.. The difference is that the experiments will be unsuspecting generations of school children.
I also guarantee that a voucher system would have a massive uptake in church schooling.. And we've never seen a Christian denomination produce scandelous steal-from-the-poor mega-churches have we? Didn't we just shut down the Taliban? Do we really need to reproduce it here? God only, science-is-from-the-devil, questioning-faith-sends-your-soul-to-hell schooling.. wonderful.. Not saying church schools don't work (Catholic schools do quite well, thank you). But in this fly-by-night churching society we have, it's guaranteed that some poor town will set up a horribly underqualified, backwards church-school, with the promise of tons of government money. Only takes 2,000 bad apples to spoil the barrel. And we've got a full 2/3 of a country full of barrel hunters.
My parents went to Catholic school, and I went to public school, and I never had a problem with their systems. My family is very well educated as a result. But my parents and myself had strict homework encouragement in our respective families. Many of my friends who never made it very far from high-school were sega-mongers afterschool with mostly absent parents (at least while we were at their houses). School was free day-care for their 14-year-olds as best I could tell.
I don't know how much public education has changed since I've been there, but I recall it as being very systematic. There was little confusion about course materials - only people that hadn't done their homework and progressively fell further behind. Classes always had feedback systems. Very rarely did we see multiple choice - most quizes involved critical thinking - no guesswork possible. Partial credit was assumed. I was actually surprised when I got to college and the proliferation of multiple choice. The D-average was possible practically by guessing and showing up to class every day. I understand the challenges of 100 students per teacher in college necessitating less critically reviewed quizes/exams, but I honestly think I got a better education (fact for fact) in public elementary and high school than I did in college. And I went to a well-ranked college.
High school was what you made of it.. I was highly motivated and had a powerful support structure at home. But by sophmore year I'd surpassed the ability of my parents to help with homework, so the only thing you can argue at that point is positive re-inforcement. I was (as many slashdotters, I'm sure) an introvert so I didn't have the daily distraction of socializing - which I fear represented my main advantage over my high school competition. The sense of excelling I'm sure was a prime motivator in and of itself (as a sports athelete is driven to rise from 3'rd place to 2'nd or maybe even first). If we had school uniforms, greater anti-social regulations in classes, I'm sure that my competition would have been much firmer and I'd have been less motivated as a result. Who knows. I will say that parents have a tremendous influence on how their children develop self-esteem. If you're told you have to make friends, doing x,y,z will make you popular or cool, funny, the life-of-the-party. If doing things (as a parent) to help your kid look cool or s
Jumping in the middle of the thread - his reasoning is not stupid. It says there is a cost to adding a layer (band-aid) which can plausibly have other side effects.
If there is a known event that produces a plausibly known negative outcome, any action that attempts to mitigate the outcome without directly addressing the source is, at best, managed chaos.
Yes, Humans have gotten very good at this, but only when we have an extremely high degree of confidence of all the possible parameters. The parent is expressing the fact that we do NOT have such knowledge of cause-and-effects with respect to changing the chemical distributions of our highly complex oceans (it's only the cradle of life for God's sake).
Because the central government doesn't collect sales taxes, only the local governments. And in many states, there are lots of businesses near state borders (NYC, DC, Philly, Las Vegas, Las Angeles, etc). As a local mayor (or governor), you want your local prices to 'seem' as low as possible so you can solicit money from adjoining towns/cities. The best way to do this is to have advertised prices 'seem' lower.
A local shop knows that idiots round down the cents.. So $99.99 is "under a hundred". Likewise morons think $4.09.99 for gas is really $4.09 (because the sub-sub number is really really small on billboards). Psychologically given two vendors within eye-shot of each other, the one advertising $100 is going to lose business to the $99.99 billboard.. Technically it is cheaper, but if you happen to be down-road, it obviously won't even pay for the extra gas.. But the psychology is that 'other stuff might be cheaper too', and 'every little bit counts', 'A penny saved, is a penny earned' (truer when people actually 'made' pennys / hour)
If you include taxes, the $9.99 becomes $10.48.95 at 5% (typical state sales tax). Which means the vendor needs to charge below $9.49 to avoid "sticker shock" of 1/100th of a penny. A 50 cent loss to the vendor. Since MOST goods advertised at $x.99 are really between $1 and $10, this is actually a very large percentage. $0.99 becomes $0.94 (5.05% loss in revenue). And that's only for 5% taxes.. 10% taxes (DC and other touristy places) would equate to heaftier losses.
Again, this is the very real, provable and scientific proposal that idiots (defined as 99% of us) make buy-or-fly choices based on exceeding or avoiding nice round numbers.
As condescending as I might sound, I personally succumb to the relative discount phenomena. If you go to a restaurant where they show $60 steak on the menu, the $20 pasta and $5 glass of water looks like a bargain. Course I only eat out twice / year.
* no flicker
* INSTANT on
* INSTANT max-brigtness
* 5W v.s. 16W for a 700lumen bulb replacement LED v.s. CFL - efficiencies scale better for LED than CFL for lower lumans, but benefit CFL for higher lumans.
* lighter
* more durable
* no mercury
* longer life expectancy
The two negatives are the color spectrum and price of LEDs. You can get very nice ranges of colors in CFL's these days (soft, white, 'natural daylight'). The few LED lights I've sampled have very distinct colors.
CFL's are already cheaper than incandecents even if you ignore energy costs (due to 1/4 to 1/10th the replacement schedule). LEDs advertise 6x the life of CFLs. While I'm aware of CFL's not all being equal - cheaper brands get 70% of their advertised life, while many name-brands get 120% of their ratings. LEDs haven't had anywhere near the public testing (because there aren't enough volume vendors to test against).
I read all the wiki had to offer. I agree that this is a problem - I'm going to see if I can post to their complaint forum as well.
Basically you have a URL that contains 4 pieces of information.. A file name (largely meaningless except to the end user), a file-size, and 3 30-Byte SHA-1 hashes, referred to here as a 3-tuple (represented in HEX). You search the local disk cache for file names that match each of the SHA-1 digests. For every digest file not found, search the local network for a match and download the block locally (this is the peer-to-peer part).
You XOR the contents of the 3 blocks (which happen to be sized at 128K - no significance) to produce the decoded data.
The first decoded block (provided from the URL) is a sequential-list of 90 byte 3-tuples (similar to the original URL). The contents of all of these 3-tuples are the desired data, except the last 3-tuple which is a chain to the next descriptor block.
The file-size tells you when to stop obviously.
The 'theory' is that highly randomized data should be randomly reused by completely unrelated data.. .mp3 and .txt files, for example. Moreover, there is 'no way to reconstruct' useful data w/o the 3-tuple AND the file-size. However, small files will have a high probability of SHA-1 collisions (and thus corrupted data - they only talk about virus corruption, but there's the more important inadvertant collsions which overwrite valid data - BackupPC resolves this by creating MD5;1 MD5;2 file-names). The large 128K should alleviate this, but also assures a low probability of block reuse.
The problem I see is that data-blocks are not inherently random by default.. In order to be practically random, you'd have to take the recommended 1TB file-system, randomize it - produce approx 8 million SHA-1 digests, then for each real-data insert, delete in an LRU fashion. Otherwise, if you only had a hundred-thousand blocks - It would not be THAT difficult to grab the first 30 bytes of every block and XOR them with several of the most recently inserted blocks until you found something that matched an existing file-name. If matched, try the next 30B, etc. Now you have a starting point AND the appropriate 3-tuple. You're only missing the file-size.. But if it spits out music in one of like 5 codecs, you've got a winner. Shouldn't be able to do statistical analysis to find random-noise or invalid media format. Many files contain internal end-of-file signifiers (.zip, .gz for example).
With 8 million records, that becomes hard(er) to do. But how long does it take to initialize that?
Now with respect to the network, there's no need to actually store the file-descriptor block remotely, Thus for highly sensitive files, you can probably encrypt the descriptor block and keep it locally (sharing on a private trusted network). But for text-based files, you'd probably still be weary of having network stored timestamp ordered data-blocks - as the contents of the last 100 blocks could easily be determined, (text files are not as order sensitive as mp3s and zip files).
The stated goal is purely open, freely shared, perfectly legal data-store... Which allows the occasionally masked sensitive data. Though the RIAA/MPAA would read it as, a front for illegal data.
They say they have better bandwith than obscured P2P networks, since you can allow open download by the RIAA as well as your clients, and it's all meaningless w/o the starting points/blocks. You do have a 3x bandwidth over a pure HTTP/FTP download - as you have to download 3 blocks to XOR against each other to produce 1 block of data. They suggest that once you have a descriptor block you 'should download the tuples in random order to reduce pattern matching by ISPs' which furthers the notion that this is for illicit purpose.
I'm highly suspicious that the SHA-1 digests produce useful collisions and provide you bandwidth reduction via your local disk-cache for the above comments.
I'm also
General rules:
1) Unrelated code should not be capable of interfering with each other (liberal use of unique package-name-spaces)
2) Load order should not affect the outcome of the application (php/jsp/javascript include-files)
3) Transient data should naturally expire (block-scope or ref-counting or garbage-collection)
4) Side effect programming should be avoidable.
5) Where possible, data should be immuteable (a specialization of item 4)
6) Where possible, code should reflect hierarchical abstractions, where the least amount of information is needed to follow or use a code snippet (this encompases data-hiding, procedures/functions with minimal input parameters, function-names / variable-names that naturally match the intended execution).
7) Code (the language) should be expressive and concise. You should be able to do a powerful thing with a few lines of code. A regular expression, a SQL statement, a lex/flex BNF-form expression, a prolog-rule. These are well-thought-out highly capable and flexible sub-languages. To whatever degree your code can leverage multiple languages (presumably by leveraging libraries that interpret syntax differently at different sections of your code), your code will have fewer bugs, be easier to make small changes that have radically different outcomes, and be easier to read - At the expense of more training time for new coders.
8) A language should be a building block, such that coders do not need to start from scratch - but instead search for the module/capability, and instead of coding, you are 'wiring' the 3'rd party library to act as you intend. This is as much a social issue as a language issue. If a language has a single repository / standard, it's easier for this social dynamic to occur. If, like C, most vendors do not play well with one another, you will be hard pressed to expand on a repurposeable building block.
9) Code should lend itself to run-time analysis. Debugable, steppable, stack-traceable, efficient and run-time configureable log-file emmission (log4j and friends is a nice framework), live thread-execution analysis (with little or no obstruction), memory allocation analysis (histograms of data-types, both count and size).
10) Code should be unit-testable. This isn't as easy as it sounds.. This means all references to dates and other OS resources need to be abstracted such that a unit-test can mock an OS resource. This also means the setup of a code resource (beit a class instance or the setup of global variables (ick)) should be sufficiently simple that the unit-test does not need to test the configuration aspect of the code; just the code itself. Note that unit tests don't necessarily need to have 100% code-coverage (as many philosophies dictate), BUT when there is a production-environment issue that needs resolution, the ability to divide-and-conquer the problem by QUICKLY throwing together specific unit-tests is indescribably valuable. Code that is not designed with the idea that it MIGHT be unit-tested is almost impossible to do this with. Languages that facilitate unit-testing are also invaluable.
11) Naming conventions should be consistent within a project.. And ideally across the language. XXImpl, XXBean, xx getXxx(), setXxx(xx), XXFactory, XXAdaptor, XXReader, XXWriter, XXController, XXDAO, etc, reduces the learning curve for any API.
12) Inputs and Outputs of any function/procedure must be absolutely clear.. If you're sadly using a language that requires 30 input parameters for a procedure/function, and the language doesn't have sensible defaulting capabilities (overloading or default field parameters) then A) shoot-yourself B) write an adaptor which minimizes the inputs. Create XXAdaptor adaptor code with setXX(x) and xx run(); that uses appropriate/sensible defaults.. This should work for most any language.
13) Reduce the impedance mismatch between unrelated code. A standard imposed by the language (InputStream, OutputStream, Runnable, Method, Reader, Writer, Co
Believe me, I prefer message passing system. I'm not knocking them in any way. When given the chance, I reorganize code into stateless (rather self-contained, context-free) serializable messages - in the case that they might need to one day transport onto an alternate clustered node.
However, I've recently had to deal with a problem that required a massive in-memory priority heap (hundred million DB records with 100k in-mem group/category descriptors). The best you could do is partition the data-set across multiple clustered nodes then write in synchronization routines which guarantee you're pulling the next highest priority item (either from a local node or a remote node).. But in our case the working set could fit in memory, and clustering would have been a lot of extra potential for bugs - far outweighing the probability of race-condition bugs (which are far worse than dead-locks, because they're silent but deadly).
A pure DB solution was deemed far too slow for many common mass-data manipulation events. Not to mention the transient nature of the priorities.
In this case, a trivial fail-over detection with a semi-idle slave node was sufficient. Semi-idle in the sense that there were truely clusterable activities that occurred on the same hardware (namely the real-time responses to the prioritized messages).
Message passing systems and MT systems solve different problems. Consider that Message Passing is a subclass of Multi-Processing; in general the amount of work is much larger than the data-set. But Multi-Threading often involves many micro-changes to a large message (the entire state of the process).
Consider an in-memory database. (Mysql-cluster (NDB), for example). You wouldn't want to pass the entire database around (or even portions of it around) for each 'job'. Instead, you'd like at most only partitions of the data where massive working-sets reside on each partition and do inter-data operations. Then your message passing is limited to only interactions that aren't held in the local memory space (i.e. NUMA).
With Terracotta you are breaking a sequential application into a series of behind-the-scenes messages which go from clustered node to clustered node as necessary (I'm not very well versed on this product, but I've reviewed it a couple times).
Thus for certain problems that do not nicely break down into small messages, you are indeed limited to single-memory-space hardware. And thus, the more CPUs (that leverage MESI (sp?) CPU cache) the more efficient the overall architecture.
Now, I can't imagine that a 768CPU monster is that cost effective - you're problem space is probably pretty limited. But a simultaneous 700 thread application is NOT hard to write in java at all. I regularly create systems that have between 1,000 and 2,000 semi-active threads. But I try to keep a CPU-intensive pool down to near the number of physical CPUs (4, 8 or 16 as the case may be). Java has tons of tools to allow execution-pools of configureable size.
Correction. The Big 5 US carriers facilitate 160 physical characters per chargeable SMS message. Some carriers have overhead that reduces this somewhat, and message concatenation consumes 7 to 10 character slots(8-bit bytes if you prefer).
I also like how people are quoting under 15 cents per message (sending AND receiving). Have you checked your bills lately?
The real rip-off however is not SMS, but MMS (at $1.50 each).
Consider that if you've ever done UNIX programming, you've been doing MT programming all along - just by a different name.. Multi-Processing. Pipelines are, in IMO the best implementation of parallel programming (and UNIX is FULL of pipes). You take a problem and break it up into wholly independent stages, then multi process or multi-thread the stages. If you can split the problem up using message-passing then you can farm the work out to decoupled processes on remote machines, and you get farming / clustering. Once you have the problem truely clustered, then multi-threading is just a cheaper implementation of multi-processing (less overhead per worker, less number of physical CPUs, etc).
Consider this parallel programing pseudo-example
find | tar | compress | remote-execute 'remote-copy | uncompress | untar'
This is a 7 process FULLY parallel pipeline (meaning non-blocking at any stage - every 512 bytes of data passed from one stage to the next gets processed immediately). This can work with 2 physical machines that have 4 processing units each, for a total of 8 parallel threads of execution.
Granted, it's hard to construct a UNIX pipe that doesn't block.. The following variation blocks on the xargs, and has less overhead than separate tar/compress stages but is single-threaded
find name-pattern | xargs grep -l contents-pattern | tar-gzip | remote-execute 'remote-copy | untar-unzip'
Here the message-passing are serialized/linearized data.. But that's the power of UNIX.
In CORBA/COM/GNORBA/Java-RMI/c-RPC/SOAP/HTTP-REST/ODBC, your messages are 'remoteable' function calls, which serialize complex parameters; much more advanced than a single serial pipe/file-handle. They also allow synchronous returns. These methodologies inherently have 'waiting' worker threads.. So it goes without saying that you're programming in an MT environment.
This class of Remote-Procedure-Calls is mostly for centralization of code or central-synchronization. You can't block on a CPU mutex that's on another physically separate machine.. But if your RPC to a central machine with a single variable mutex then you can.. DB locks are probably more common these days, but it's the exact same concept - remote calls to a central locking service.
Another benifit in this class of IPC (Inter Process Communication) is that a stage or segment of the problem is handled on one machine.. BUt a pool of workers exists on each machine.. So while one machine is blocking, waiting for a peer to complete a unit of work, there are other workers completing their stage.. At any given time on every given CPU there is a mixture of pending and processing threads. So while a single task isn't completed any faster, a collection of tasks takes full advantage of every CPU and physical machine in the pool.
The above RPC type models involve explicit division of labor. Another class are true opaque messages.. JMS, and even UNIX's 'ipcs' Message Queues. In Java it's JMS. The idea is that you have the same workers as before, but instead of having specific UNIQUE RPC URI's (addresses), you have a common messaging pool with a suite of message-types and message-queue-names. You then have pools of workers that can live ANYWHERE which listen to their queues and handle an array of types of pre-defined messages (defined by the application designer). So now you can have dozens or hundreds of CPUs, threads, machines all symmetriclly passing asynchronous messages back and forth.
To my knowledge, this is the most scaleable type of problem.. You can take most procedural problems and break them up into stages, then define a message-type as the explicit name of each stage, then divide up the types amongst different queues (which would allow partitioning/grouping of computational resources), then receive-message/process-message/forward-or-reply-message. So long as the amount of work far exceeds the overhead of message passing, you can very nicely scale with the amount of hardware you can throw at the problem.
What does javascript and java syntax have to do with one another? Javascript is closer to VB-Script, which I still convulse when I remember my prison days of working with. I only like loosely typed / late-binding language for rapid prototyping languages. Python, perl, bash, javascript, awk. But I don't like the negatives with that late-binding when it comes to advanced middleware. The code-base is far too fragile, and you don't get a whole lot of code-reduction in the syntax (to your point of verbosity).
.h files for every 5 line .c file), and is structurally identical to C++; a mixture of procedural and OO coding. Contrast this with a functional language which, for a given domain, can be far superior in term of visual clarity of the presented code.
Now SQL, ruby, and prologue are three radically different syntaxes which I find some beauty in. But to me Java, C, C++ are all VERY similar (by design). While java has statistically more characters in a given bundle of code, it has a far superior compilation framework (don't need to compile 5 meg of
Every language has it's niche, and the further you deviate from that niche, the more you stick out like a sore thumb.
You (as well as many) are focusing on the verbosity of the language. But there are sufficient tools which mitigate the verbiage of java. I, on the other hand, am focusing on the feeling I get when I'm programming in the language (kind of like dating the language). Am I frustrated by things that I feel we shouldn't be worrying about in the 21'st century? How robust is my peer's code? How packageable/encapsulateable is it? Can the language constrain his deficiencies? In C, no. In C++, maybe a little better. In javascript, no. In perl, you'd have to do something weird (like flip package spaces). In Java, definitely. So this amongst dozens of other nuances, makes the language feel more elegant and pleasurable to work in.
Consider documentation. In perl, there is sufficient magic to keep a single person employed for a long time. In javascript, documentation is often only at the highest level (here, use this example). In C, lord help you - you had best pray the documentation has been kept up to date. In Java, you don't even need documentation - the strictness of the language allows you to dynamically ascertain all possible calling conventions (with the possible exception of a 10 integer static function where you don't know which parameter means which - but in my experience, most 3'rd party functions have only one or two parameters). There is no code you can link against in java that you can't [auto]discover it's intended interface.. And the verbosity of the language is self-documenting. public class MyOptimizedXmlFactory { public static XmlReader createReader(File){} } is kind of hard to mis-interpret. In fact, the language is so well structured, that javadoc can build an entire web site from literally any existing code that defines every possible useage pattern (except for unnamed parameters as described before - though well documented code will properly annotate the parameter useage).