Vogels was a distinguished academic in distributed systems prior to Amazon. Read his blog some time. He is quite insightful, and this queuecast was a great one. Yours is the first comment I've seen in many forums over the past few months that seems to think it was tripe, so I find it curious.
His point is that Amazon has found that a decentralied archtiecture that can work reliably but still respond to new demands with agility. That's a huge deal, considering the contortions, pain, and centralized bottlenecks that most large IT shops have to deal with. Not to mention over-obsession with technological buzzes instead of looking at the business architecture of the firm.
Perhaps that's obvious, but perhaps it's important to restate the obvious when most people don't follow it.
The best resource (though getting dated) on the origins and meaning of shared nothing v. shared-something archticture is Greg Pfister's In Search of Clusters, 2nd ed..
There's "degenerate" shared nothing, which is what I find most people referring to today -- you have web server farm and you don't store session state, or if you do, you "pin" it to a particular server. Or you just rely on the database. It's degenerate because, sure, it's scalable (memory isn't as directly linked to concurrent users), but it really just shifts the burden to the database, which tends to be 1 big box.
So the question becomes, how do you scale the database horizontally?
In the database world, the term has become somewhat overloaded. Originally it meant physically shared disks and/memory vs. using network interconnectivity. But with the rise of I/O shipping technologies over networks (iSCSI, high speed NFS/NAS, SAN fibre-channel), this isn't really true anymore. So now, it comes down to how your data is partitioned and how you ship a read/write function to that node. Does a node "own" it's data (or a replica)? Or can any node touch any data? That's the debate.
In short, it works well in some cases: read-mostly parallel queries and/or search, which is why Google's using it, or why you see it with data warehouses (Teradata, DB2 UDB). It works OK if you have mostly have transactional data updates within a well-defined partitionable set of data (such as the TPC-C benchmark). It works less well when dealing with transactional updates spread across the entire data set (assuming a normal distribution), as you'll need to update replicas with a two-phase commit. The load balancing of your data across nodes also requires care in picking the appropriate partitioning key: sometimes a hash works well, sometimes range-values work well. If you need to re-partition your data for whatever reason, it's going to be a big job.
Commercially, Oracle 10g's Real Application Clusters is an example of a shared disk database, though they use an interconnect between nodes for cache coherency. Microsoft SQL Server, DB2, Teradata, MySQL, etc. are all "shared nothing".
Analysts are there to guide investors on what is value, what is growth. Apple is clearly not "value". Analysts that said "sell" Apple stock in 2004 and kept saying it stubbornly in the face of such performance should be out of work.
I've done this with both a Dell and Acer laptop a couple of times I've had the seat plug -- the laptop was in "charging" mode and the battery would go down very slowly... on a 3 hour flight maybe 10-15%.
I owned a Powerbook G3 Bronze Keyboard, first gen 15-inch Powerbook G4 Titanium 500mgz, first gen 17-inch Powerbook G4 1ghz, and now a first gen 15-inch MacBook Pro 2 ghz.
I've had no problems with any of them, they were very reliable computers. Until the MacBook Pro. My battery has cut out three times in the 3 months I've owned the laptop, 2 being in the last week -- I will be seeking a replacement bettery. On the bright side it's not swollen (yet).
Because HTTPS only offers point-to-point security.
Well, arguably HTTP is end-to-end transfer protocol. SSL proxying can and does happen all the time, what really matters is whether the intermediary is "trusted" + "active" or "untrusted" + "passive". The same applies to WS-Security with XML DSig.
If you need to encrypt or authenticate through a web service proxy (e.g. an ESB) you can't guarantee or prove the security of the document from point A to B to C.
If you have an intermediary that's doing *anything* to the unencrypted message, you can't guarantee the end-to-end security of the document. An ESB would just be passive monitor in this case.
Now, there is an argument that "parts" of a message should be opaque/secured with one certificate, and other parts should be visible to the ESB through another certificate. But that's getting pretty complicated... I can see this in a huge service network, but broadly speaking such beasts don't exist yet.
Also, SOAP can run over SMTP and other transport protocols.
Sure, though you'd probably need to justify the use case...
So if either of those situations are a requirement for your architecture, HTTPS doesn't just plain work.
Granted, but those cases should be the exception, not the norm. If they are the norm, in my experience you are likely in one of three situations: a) making assumptions that are over complicating the architecture, or b) dealing with a political environment where simplicity is scorned over tradition/heritage/risk aversion, c) you are (or think you are:) working in a specialized domain with unique security, performance, or auditability requirements.
This is probably the first time I've seen the idea presented that the there is a concerted conspiracy keeping the potential supporters of the oil industry down.
"Keeping the world safe for billionaires" seems to be the primary agenda for current western 'conservative' regimes. Examples of the above are rife in multiple areas:
there is a conspiracy to destroy intellectual property and starve all the poor software developers, artists and record labels by these P2P and open source ideas... left-wing professors and idealistic college students don't know what's good for them!
there's the classic socialist conspiracy, popular in the US, that says that anyone that actually wants to provide universal healthcare or other useful government services really just wants to control your life and spend your money
there's the immigration conspiracy, that we're losing jobs/culture to those damn immigrants
the chinese apparently have conspired to undervalue the yuan, making their exports cheaper than they should be, depriving americans of jobs
apparently 'free trade' should only flow one way -- outside of the u.s. borders. if there's a threat to u.s. agriculture, steel, softwood lumber, or other heavily subsidised industries, the other countries obviously are "cheating" and thus the u.s. must balance this with tariffs (often at the protest of the WTO).
pacifists and greenpeace are really just trying to hurt the livelihoods of thousands of hard working defence contractors, animal rights lobbiests are conspiring to destory the american livestock/dairy/etc farmer in favour of a vegan world, etc.
I could go on... people like to defend their powerbase with both asinine and compelling arguments, but the emphasis tends to be on the former , especially if you're entrenched..
Streaming XML parsers definitely would raise an error on the lack of well-formedness if you requested that portion of the document... The trick is whether only a subset of the document needs to be read or not. A SAX-based parser is the classic example, with a parser available for JavaScript.
All I can do is wish that there was a sane, well-crafted, easily-parsed, fault-tolerant binary specification which enjoyed the same ubiquity.
Well, it doesn't solve all of the above, but YAML is a great alternative, I think, particularly for config files or anything human readable. It doesn't quite have the ubiquity or breadth of support for parsing/querying, but it's got uses.
Since when do standards bodies make for a higher quality specification? They exist as a political process to ensure a wider 'supported' specification & to ensure stakeholders get their say at the table.
The Java langauge spec is very well defined, and there's more than one reference implementation of a JVM available to study... which is why you tend to see a lot of separate codebase VMs for Java (Sun v. IBM v. BEA JRockit v. Aonix v. kaffe v. GCJ) and value added derivatives of Sun's implementation (HP has variants for Tru64, UX, OpenVMS, and NonStop, and some have OS-particular features). Compatibility wise, they broadly work well with minor issues -- see BEA's support matrix, for example.
Sure, one of the benefits of classic HTML is that it's more forgiving than well-formed XML.
Having said that, well-formed XML is a very, very low bar of standard one can set for a data representation. I think you're stretching to suggest that one requires "bug free software" to generate well formed XML. One certainly can have buggy software and generate well-formed XML! But it's not much to ask for well-formedness, especially if you're dealing with machine-targeted document exchange! That's the biggest use of XML -- not for humans to write it, but for machines read/write it. WIth human-generated markup, like HTML, then it's certainly much more prone to typos and bugs, and I agree that XML's lack of grace doesn't help much, and its use for config files can be annoying for this reason.
Sure there are other ways to represent data -- but not everyone will understand them, and there won't always be easy to understand rules to expand them when you need to add things to that representation (different text encodings, comma delimited files for example have different ways of handling escaped characers, how about when you need to start nesting data structures, etc)
As for your examples relating an XML document to a TAR file, I don't see your point... if i have a streaming-oriented XML parser, I can extract things in a later position in a corrupt document without it breaking. If it's truncated, no big deal - it hasn't hit that part yet anyway. If there's corruption in the middle of the doc, usually there are ways to allow the parser some leeway in interpreting the stream. The trick is to stay away from annoying DOM parsers.
Marketing doesn't need a corporation behind it... Maoists and communists were doing it as well as capitalists (and better than them, in the earlier parts of the century).
Quantum*Link for the C64 (the AOL predecessor) was the first that made steps towards a true graphical experience (such as the Lucasarts Habitat environment or Club Caribe, which forshadowed World of Warcraft and other MMORPGs..). This was in 1986ish...
Personally, I would think that no closed-source application should ever be used in a secure network environment. That includes the OS, obviously. There's just too much stuff that a closed-source application could be doing that isn't good, even if there was no malicious intent.
Sure, but as Bruce Schneier says, open source does not mean "fewer bugs", necessarily. It does mean the potential of wider expert peer review.
An interesting question I have is whether the non-OSI "shared source" licenses would be sufficient to meet the needs of an organization's security? Open source values the number of eyeballs, but the eyeballs evaluating security challenges needs to be expert eyeballs, thus de-emphasizing the need for a freer license....
Many mainframe systems can process orders of magnitude more transactions than your typical *nix system running Oracle
The key word is 'typical'. One of the reasons the mainframe excels is twofold: higher-performing, tighter-coupled databases (VSAM or IMS) and the long standing discipline of true performance analysis and capacity planning that barely exists in the open systems / distributed world.
If looking at the merits and capabilities of the software itself, a well designed SMP or clustered *nix envrionment with Oracle can run rings around mainframes. The reliability of a store like Amazon is worth millions a second. Google too. Likely their financial (perhaps not liability) exposure is similar to those that traditionally use mainframes. The issue tends to be that most admins and architects thrown at these things are have very compartmentalized specialities (OS guys don't talk to Oracle guys don't talk to sw guys don't talk to network guys), so you get a culture of finger pointing.
Of course, bad planning hit mainframe environments too -- I've heard a story of one environment whose multiple regions were polluted by a shared SAN between dev and production. A dev Linux blade cluster started pumping WebSphere MQ messages into the dev mainframe LPAR with a bad format, which was generating log messages at the rate of 5 MB/second, frantically requiring the mainframe admins to delete logs every few seconds to hopefully not overwhelm production with a disk full error.
I don't work for Rogers (anymore) but this is my understanding:
Rogers doesn't do packet inspection, they do bandwidth shaping based on the connection patterns / ports of your computer.
Also note that they don't block the VoIP port because many services including Vonage (I believe) use that port; it would be a lot of angry customers if they throttled it. Rogers Home Phone runs either with a Sprint/Call-Net local loop or on a seperate Rogers Hybrid Fibre/Coaxial VLAN with a separate battery-backed up telephony modem, so it's completely fault tolerant to Rogers Hi Speed Internet.
I recall Rogers claiming that something obscene like 45-60%+ of all Rogers Hi-Speed Traffic was BitTorrent through 2005, which is what led to these measures in late 2005. I don't like them either, frankly, and wish at least they would provide options where we can pay for increased quality of service instead of resorting to workarounds. If they block the VOIP workaround port (which always works fine for me), they will likely lose a number of multi-product subscribers fed up with the restriction, which Bell Sympatico doesn't (yet) have.
Though I would say I did it less for becoming a DBA and more for being a developer or architect with strong DBA skills. I found the OCP has the problems that most paper certs do , and not everyone in the Oracle world respects them. But it's a good way to force you to learn the product (assuming you do spend time learning beyond the exam-cram stuff).
Having said this, I took the cert before the course requirements were mandatory. If you're paying for this yourself, I'm not sure the courses are worth the thousands of $$$ if you're a good self-learner. OCP won't give you THAT much of a salary increase.
Writing a trivial program in Windows is quite easy in VB or VB.NET, I know of kids that can do this today, and could back in the mid-1990's. In Win32 C, sure, it's quite rough, but not even professional developers really do that anymore (they at least use C++ and MFC. And speaking from experience, I couldn't figure out Win16 when I was 14, but I could figure out the early versions of MFC and VC++ 3 and 4 (though barely). VB was much easier, as was Java 1.0's AWT.
Though arguably one can learn a lot more by reading, understanding the ideas behind what already exists, and fiddling with that, instead of crafting trivial programs from scratch. I recall the days with Logo as an example of this, when I was a child. Putting together crappy little C64 Basic programs also helped. But frankly it didn't teach me good habits or anything about "why" I may want to do something a certain way. It was when I read code from others in C64 assembly or basic that I really started to "get it". And then as I moved to other languages, great examples of code helped to show the way (in C, in Smalltalk, in Lisp, etc.).
PRO/Engineer arguably doesn't provide the intuitivity necessary as an exploratory environment, also because there is a large body of non-obvious theory behind its application. In programming, there is also this body, but I find you can at least get some meaningful feedback with small gestures to start with.
I really enjoyed the essay on the early history of Smalltalk. The PDF has fewer OCR errors. In particular, how it was used with children is an insightful example of the challenges of learning to program.
From the essay:
For example, Marion Goldeen's (12 yrs old) painting system was a full-fledged tool. A few yuears later, so was Susan Hamet's (12 yrs old) OOP illustration system (with a design that was like the MacDraw to come). Two more were Bruce Horn's (15 yrs old) music score capture system and Steve Ptz's (15 yrs old) circuit design system. Looking back, this could be called another example in computer science of the "early success syndrome." The successes were real, but they weren't as general as we thought. They wouldn't extend into the future as stringly as we hoped.
And on teaching adults:
It started to hit home in the Spring of '74 after I taught Smalltalk to 20 PARC nonprogrammer adults. They were able to get through the initial material faster than the children, but just as it looked like an overwhelming success was at hand, they started to crash on problems that didn't look to me to be much harder than the ones they had just been doing well on. One of them was a project thought up by one of the adults, which was to make a little database system that could act like a card file or rolodex. They couldn't even come close to programming it. I was very surprised because I "knew" that such a project was well below the mythical "two pages" for end-users we were working within. That night I wrote it out, and the next day I showed all of them how to do it. Still, none of them were able to do it by themsleves. Later, I sat in the room pondering the board from my talk. Finally, I counted the number of nonobvious ideas in this little program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them.
Rogers in Canada, for example, throttles BitTorrent traffic by detecting how many hosts you're connecting to. It's also screwing up iTMS. Fortunately, there's a known workaround (using well-known VoIP ports), because I don't think they're ready to handle thousands of screaming Vonage customers affected by this shit policy...
Firstly, that's just not true by any stretch of the imagination. Oracle makes more money than RedHat's , Boss, or MySQL's combined annual revenue in a matter of HOURS.
Let's also recognize that "market" implies economic exchange. Share of market is $revenue$, not merely downloads or usage. If everyone runs an unsupported copy of MySQL, it doesn't really hurt Oracle too much in the short run, as there's no money to be made there, and it's not Oracle's target market. It hurts them in the long run due to a shrinkage of the market due to commoditization.
Having said this, a Relational Database is much, much more complex than an operating system, and it's going to be at least another decade before it's close to commodity / unsupported status.
Open source's advantage is not in eating market share (which would take around 20 years, at best). It's in shrinking the size of the market by eliminating license revenue, and reyling mostly on marketing (not a salesforce) to drive subscription revenue. It's unclear if that's a sustainable business model, but it's the one that most vendors seem to be adopting (MySQL, JBoss, RedHat, etc.)
Focus on what's rare in the market, and you will have lots of success.
For example, the IT job market will always require people with insight, perspective, and an ability to clarify. I don't care if you call these people "managers", "team leads", or "architects", but I think it really just comes down to an ability or talent to map one domain (a business or industry) to technology, without force fitting technology onto the domain.
This talent is needed everywhere: IT development, IT management, infrastructure planning, in software vendor product development, consulting or contracting, etc. IT sorely lacks people with insight and perspective -- a balance of depth and breadth. They have lots of specialists that can't look up from their narrow area, they have generalists that know very little about any one thing, but are good enough with juggling personalities and strengths that they make OK managers. What we need are people that are specialists in several areas, and an ability to synthesize. -- how to apply technology to an industry, and knowing various technology specialities.
For example, a.NET or Java designer/architect/developer (pick your buzzword) that also understands the telecom industry or pharmaceuticals, but also has deep DBA skills in Oracle and MS SQL Server, and understands TCP/IP deeply (even maybe knows how to administer Cisco routers) is a rarity, and will be compensated handsomely. Why? Most IT failures occur because project members don't understand the business needs, or misuse the database or network, and none of the dev, dba, or network specialists really know how to deal with one another.
It's not like any of these topics are particularly hard to learn -- it's just that most people tend not to mix specialities for a variety of religious reasons (developers hate DBAs and vice versa, PHP developers hate Java devs, etc.), and many people are too interested in bits & bytes , thus don't want to look at the broader world outside of technology to understand their industry deeply.
Even in a global talent pool, there will always be a need to attain and grow local talent, for simple logistical reasons (same time zone, same language, same culture ==> easier to plan).
The challenge wtih IT is that there are lots of people that don't really want to be doing this work, there are lots of people that also shouldn't be doing this work (but wound up in the industry by accident), and lots of people so ground into dust by bureaucracy or petty tyrants that they're just retired on the job. You need to have lots of passion and endurance to keep the momentum. Once again, you'll be rewarded for this attitude, because it's so damn rare.
As someone who has used Oracle's support, among others (Cisco, Sun, IBM, Microsoft, BEA), I can say that many of the large players have very good support once you get into Tier 2 or backline. These support professionals are dedicated to customer problems, unlike devs in a smaller org who often have engineering commitments. It's a balance.
I know that Cisco is renowned for their quality supoprt. Oracle has been crappy as of late due to some management and outsourcing mistakes, but had been quite good a few years back in my opinion. BEA's support website won an awared from the support professionals association for one of the "best support websites" last year, if I recall.
I think there's truth that small companies tend to have less bureaucracy and hence it's easier to find people that know what they're doing , but it doesn't follow that large companies don't have similar quality support professionals, or that their processes can be optimized to reach the appropriate person at the right time.
A falsehood is to suggest that open source has anything to do with quality of paid support -- it's more BigCo v. SmallCo tradeoffs.
As I've posted below, I disagree with this. I've owned a Thinkpad T60 and various other Thinkpads over the years, along with Dells, Acers, and several Powerbooks. The aluminum Powerbook 17-inch G4 was the best of them all for durability, maintainable looks, and performance. Every one of these wound up requiring repairs after 2 years of sustained use and travel, but the Powerbook is still chugging along quite well with few noticable scratches, and no notable problems (other than the G4 1.33 getting a bit long in the tooth).
Take the MacBookPro. Pick it up in one hand along an edge. If you can't see the entire damn case flexing, I'll eat my UPS.
Get off your bloody high horse. I'm holding the one I just purchased last week by an edge right now..... Hmm. seems fine to me. (as was the AlBook).
Look, I guess if you like to play laptop frisbee and work in a ditch all day, I can see the desire for ruggedized plastic. But frankly the annodized alumnium has been the best durability/looks combo of a laptop that I've experienced. And I have plenty of data points to compare it to.
I have a lot of Thinkpad-fan friends and their major reason for liking it is the nipple vs. trackpad debate, which frankly seems like a religious issue that will never go away... I admit I've had some shitty trackpads but the Powerbook/Macbooks are quite nice (the Acer's Synaptics pad was the nicest IMHO, but sadly that was 4+ years ago )....
I've been through a lot of laptops: Thinkpads in the mid through late 1990s, Dell Insipiron 8000 and 9000 series, Dell Latitude D600 and D800, Acers, Powerbook G3, Powerbook G4 titanium and aluminum, and now the MacBook Pro.
Out of all of these, the most durable and problem-free was the 17-inch Powerbook G4 alumnum 1.33 ghz. It still looks great 2.5 years after I purchased it after _heavy_ airline travel, use, and abuse, in many locations, grabbing it via one hand, etc. I've had to replace the power adapter once because it began to split at the end, due to repeated yanking / bending -- that's all. The actual laptop case does not scratch or bend anywhere near as much as the plastic cases of the other laptops. The Titanium G4, FWIW, was rather flimsy and had paint that scratched easily.
Other than the processor whine, which I don't usually hear, the MacBook Pro has the same durable feel and construction of my AlBook G4, and I'm looking forward to many a year with it.
Vogels was a distinguished academic in distributed systems prior to Amazon. Read his blog some time. He is quite insightful, and this queuecast was a great one. Yours is the first comment I've seen in many forums over the past few months that seems to think it was tripe, so I find it curious.
His point is that Amazon has found that a decentralied archtiecture that can work reliably but still respond to new demands with agility. That's a huge deal, considering the contortions, pain, and centralized bottlenecks that most large IT shops have to deal with. Not to mention over-obsession with technological buzzes instead of looking at the business architecture of the firm.
Perhaps that's obvious, but perhaps it's important to restate the obvious when most people don't follow it.
The best resource (though getting dated) on the origins and meaning of shared nothing v. shared-something archticture is Greg Pfister's In Search of Clusters, 2nd ed..
There's "degenerate" shared nothing, which is what I find most people referring to today -- you have web server farm and you don't store session state, or if you do, you "pin" it to a particular server. Or you just rely on the database. It's degenerate because, sure, it's scalable (memory isn't as directly linked to concurrent users), but it really just shifts the burden to the database, which tends to be 1 big box.
So the question becomes, how do you scale the database horizontally?
In the database world, the term has become somewhat overloaded. Originally it meant physically shared disks and/memory vs. using network interconnectivity. But with the rise of I/O shipping technologies over networks (iSCSI, high speed NFS/NAS, SAN fibre-channel), this isn't really true anymore. So now, it comes down to how your data is partitioned and how you ship a read/write function to that node. Does a node "own" it's data (or a replica)? Or can any node touch any data? That's the debate.
In short, it works well in some cases: read-mostly parallel queries and/or search, which is why Google's using it, or why you see it with data warehouses (Teradata, DB2 UDB). It works OK if you have mostly have transactional data updates within a well-defined partitionable set of data (such as the TPC-C benchmark). It works less well when dealing with transactional updates spread across the entire data set (assuming a normal distribution), as you'll need to update replicas with a two-phase commit. The load balancing of your data across nodes also requires care in picking the appropriate partitioning key: sometimes a hash works well, sometimes range-values work well. If you need to re-partition your data for whatever reason, it's going to be a big job.
Commercially, Oracle 10g's Real Application Clusters is an example of a shared disk database, though they use an interconnect between nodes for cache coherency. Microsoft SQL Server, DB2, Teradata, MySQL, etc. are all "shared nothing".
...and then reality kicks in.
Analysts are there to guide investors on what is value, what is growth. Apple is clearly not "value". Analysts that said "sell" Apple stock in 2004 and kept saying it stubbornly in the face of such performance should be out of work.
I've done this with both a Dell and Acer laptop a couple of times I've had the seat plug -- the laptop was in "charging" mode and the battery would go down very slowly... on a 3 hour flight maybe 10-15%.
I owned a Powerbook G3 Bronze Keyboard, first gen 15-inch Powerbook G4 Titanium 500mgz, first gen 17-inch Powerbook G4 1ghz, and now a first gen 15-inch MacBook Pro 2 ghz.
I've had no problems with any of them, they were very reliable computers. Until the MacBook Pro. My battery has cut out three times in the 3 months I've owned the laptop, 2 being in the last week -- I will be seeking a replacement bettery. On the bright side it's not swollen (yet).
Because HTTPS only offers point-to-point security.
:) working in a specialized domain with unique security, performance, or auditability requirements.
Well, arguably HTTP is end-to-end transfer protocol. SSL proxying can and does happen all the time, what really matters is whether the intermediary is "trusted" + "active" or "untrusted" + "passive". The same applies to WS-Security with XML DSig.
If you need to encrypt or authenticate through a web service proxy (e.g. an ESB) you can't guarantee or prove the security of the document from point A to B to C.
If you have an intermediary that's doing *anything* to the unencrypted message, you can't guarantee the end-to-end security of the document. An ESB would just be passive monitor in this case.
Now, there is an argument that "parts" of a message should be opaque/secured with one certificate, and other parts should be visible to the ESB through another certificate. But that's getting pretty complicated... I can see this in a huge service network, but broadly speaking such beasts don't exist yet.
Also, SOAP can run over SMTP and other transport protocols.
Sure, though you'd probably need to justify the use case...
So if either of those situations are a requirement for your architecture, HTTPS doesn't just plain work.
Granted, but those cases should be the exception, not the norm. If they are the norm, in my experience you are likely in one of three situations: a) making assumptions that are over complicating the architecture, or b) dealing with a political environment where simplicity is scorned over tradition/heritage/risk aversion, c) you are (or think you are
"Keeping the world safe for billionaires" seems to be the primary agenda for current western 'conservative' regimes. Examples of the above are rife in multiple areas:
I could go on... people like to defend their powerbase with both asinine and compelling arguments, but the emphasis tends to be on the former , especially if you're entrenched..
Streaming XML parsers definitely would raise an error on the lack of well-formedness if you requested that portion of the document... The trick is whether only a subset of the document needs to be read or not. A SAX-based parser is the classic example, with a parser available for JavaScript.
All I can do is wish that there was a sane, well-crafted, easily-parsed, fault-tolerant binary specification which enjoyed the same ubiquity.
Well, it doesn't solve all of the above, but YAML is a great alternative, I think, particularly for config files or anything human readable. It doesn't quite have the ubiquity or breadth of support for parsing/querying, but it's got uses.
Since when do standards bodies make for a higher quality specification? They exist as a political process to ensure a wider 'supported' specification & to ensure stakeholders get their say at the table.
The Java langauge spec is very well defined, and there's more than one reference implementation of a JVM available to study... which is why you tend to see a lot of separate codebase VMs for Java (Sun v. IBM v. BEA JRockit v. Aonix v. kaffe v. GCJ) and value added derivatives of Sun's implementation (HP has variants for Tru64, UX, OpenVMS, and NonStop, and some have OS-particular features). Compatibility wise, they broadly work well with minor issues -- see BEA's support matrix, for example.
Sure, one of the benefits of classic HTML is that it's more forgiving than well-formed XML.
Having said that, well-formed XML is a very, very low bar of standard one can set for a data representation. I think you're stretching to suggest that one requires "bug free software" to generate well formed XML. One certainly can have buggy software and generate well-formed XML! But it's not much to ask for well-formedness, especially if you're dealing with machine-targeted document exchange! That's the biggest use of XML -- not for humans to write it, but for machines read/write it. WIth human-generated markup, like HTML, then it's certainly much more prone to typos and bugs, and I agree that XML's lack of grace doesn't help much, and its use for config files can be annoying for this reason.
Sure there are other ways to represent data -- but not everyone will understand them, and there won't always be easy to understand rules to expand them when you need to add things to that representation (different text encodings, comma delimited files for example have different ways of handling escaped characers, how about when you need to start nesting data structures, etc)
As for your examples relating an XML document to a TAR file, I don't see your point... if i have a streaming-oriented XML parser, I can extract things in a later position in a corrupt document without it breaking. If it's truncated, no big deal - it hasn't hit that part yet anyway. If there's corruption in the middle of the doc, usually there are ways to allow the parser some leeway in interpreting the stream. The trick is to stay away from annoying DOM parsers.
Really? Don't you think the UINs would uniformly have to be rather large to make such an accusation?
I own an XBox and not a PS2, does that make me a shill?
Marketing doesn't need a corporation behind it... Maoists and communists were doing it as well as capitalists (and better than them, in the earlier parts of the century).
Quantum*Link for the C64 (the AOL predecessor) was the first that made steps towards a true graphical experience (such as the Lucasarts Habitat environment or Club Caribe, which forshadowed World of Warcraft and other MMORPGs..). This was in 1986ish...
Personally, I would think that no closed-source application should ever be used in a secure network environment. That includes the OS, obviously. There's just too much stuff that a closed-source application could be doing that isn't good, even if there was no malicious intent.
Sure, but as Bruce Schneier says, open source does not mean "fewer bugs", necessarily. It does mean the potential of wider expert peer review.
An interesting question I have is whether the non-OSI "shared source" licenses would be sufficient to meet the needs of an organization's security? Open source values the number of eyeballs, but the eyeballs evaluating security challenges needs to be expert eyeballs, thus de-emphasizing the need for a freer license....
Many mainframe systems can process orders of magnitude more transactions than your typical *nix system running Oracle
The key word is 'typical'. One of the reasons the mainframe excels is twofold: higher-performing, tighter-coupled databases (VSAM or IMS) and the long standing discipline of true performance analysis and capacity planning that barely exists in the open systems / distributed world.
If looking at the merits and capabilities of the software itself, a well designed SMP or clustered *nix envrionment with Oracle can run rings around mainframes. The reliability of a store like Amazon is worth millions a second. Google too. Likely their financial (perhaps not liability) exposure is similar to those that traditionally use mainframes. The issue tends to be that most admins and architects thrown at these things are have very compartmentalized specialities (OS guys don't talk to Oracle guys don't talk to sw guys don't talk to network guys), so you get a culture of finger pointing.
Of course, bad planning hit mainframe environments too -- I've heard a story of one environment whose multiple regions were polluted by a shared SAN between dev and production. A dev Linux blade cluster started pumping WebSphere MQ messages into the dev mainframe LPAR with a bad format, which was generating log messages at the rate of 5 MB/second, frantically requiring the mainframe admins to delete logs every few seconds to hopefully not overwhelm production with a disk full error.
I don't work for Rogers (anymore) but this is my understanding:
Rogers doesn't do packet inspection, they do bandwidth shaping based on the connection patterns / ports of your computer.
Also note that they don't block the VoIP port because many services including Vonage (I believe) use that port; it would be a lot of angry customers if they throttled it. Rogers Home Phone runs either with a Sprint/Call-Net local loop or on a seperate Rogers Hybrid Fibre/Coaxial VLAN with a separate battery-backed up telephony modem, so it's completely fault tolerant to Rogers Hi Speed Internet.
I recall Rogers claiming that something obscene like 45-60%+ of all Rogers Hi-Speed Traffic was BitTorrent through 2005, which is what led to these measures in late 2005. I don't like them either, frankly, and wish at least they would provide options where we can pay for increased quality of service instead of resorting to workarounds. If they block the VOIP workaround port (which always works fine for me), they will likely lose a number of multi-product subscribers fed up with the restriction, which Bell Sympatico doesn't (yet) have.
Not every good label is an RIAA label; eMusic and Bleep.com sell lots of great non-DRM independent music.
Though I would say I did it less for becoming a DBA and more for being a developer or architect with strong DBA skills. I found the OCP has the problems that most paper certs do , and not everyone in the Oracle world respects them. But it's a good way to force you to learn the product (assuming you do spend time learning beyond the exam-cram stuff).
Having said this, I took the cert before the course requirements were mandatory. If you're paying for this yourself, I'm not sure the courses are worth the thousands of $$$ if you're a good self-learner. OCP won't give you THAT much of a salary increase.
Writing a trivial program in Windows is quite easy in VB or VB.NET, I know of kids that can do this today, and could back in the mid-1990's. In Win32 C, sure, it's quite rough, but not even professional developers really do that anymore (they at least use C++ and MFC. And speaking from experience, I couldn't figure out Win16 when I was 14, but I could figure out the early versions of MFC and VC++ 3 and 4 (though barely). VB was much easier, as was Java 1.0's AWT.
Though arguably one can learn a lot more by reading, understanding the ideas behind what already exists, and fiddling with that, instead of crafting trivial programs from scratch. I recall the days with Logo as an example of this, when I was a child. Putting together crappy little C64 Basic programs also helped. But frankly it didn't teach me good habits or anything about "why" I may want to do something a certain way. It was when I read code from others in C64 assembly or basic that I really started to "get it". And then as I moved to other languages, great examples of code helped to show the way (in C, in Smalltalk, in Lisp, etc.).
PRO/Engineer arguably doesn't provide the intuitivity necessary as an exploratory environment, also because there is a large body of non-obvious theory behind its application. In programming, there is also this body, but I find you can at least get some meaningful feedback with small gestures to start with.
I really enjoyed the essay on the early history of Smalltalk. The PDF has fewer OCR errors. In particular, how it was used with children is an insightful example of the challenges of learning to program.
From the essay:
For example, Marion Goldeen's (12 yrs old) painting system was a full-fledged tool. A few yuears later, so was Susan Hamet's (12 yrs old) OOP illustration system (with a design that was like the MacDraw to come). Two more were Bruce Horn's (15 yrs old) music score capture system and Steve Ptz's (15 yrs old) circuit design system. Looking back, this could be called another example in computer science of the "early success syndrome." The successes were real, but they weren't as general as we thought. They wouldn't extend into the future as stringly as we hoped.
And on teaching adults:
It started to hit home in the Spring of '74 after I taught Smalltalk to 20 PARC nonprogrammer adults. They were able to get through the initial material faster than the children, but just as it looked like an overwhelming success was at hand, they started to crash on problems that didn't look to me to be much harder than the ones they had just been doing well on. One of them was a project thought up by one of the adults, which was to make a little database system that could act like a card file or rolodex. They couldn't even come close to programming it. I was very surprised because I "knew" that such a project was well below the mythical "two pages" for end-users we were working within. That night I wrote it out, and the next day I showed all of them how to do it. Still, none of them were able to do it by themsleves. Later, I sat in the room pondering the board from my talk. Finally, I counted the number of nonobvious ideas in this little program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them.
Rogers in Canada, for example, throttles BitTorrent traffic by detecting how many hosts you're connecting to. It's also screwing up iTMS. Fortunately, there's a known workaround (using well-known VoIP ports), because I don't think they're ready to handle thousands of screaming Vonage customers affected by this shit policy...
"Their market share is fading away."
Firstly, that's just not true by any stretch of the imagination. Oracle makes more money than RedHat's , Boss, or MySQL's combined annual revenue in a matter of HOURS.
Let's also recognize that "market" implies economic exchange. Share of market is $revenue$, not merely downloads or usage. If everyone runs an unsupported copy of MySQL, it doesn't really hurt Oracle too much in the short run, as there's no money to be made there, and it's not Oracle's target market. It hurts them in the long run due to a shrinkage of the market due to commoditization.
Having said this, a Relational Database is much, much more complex than an operating system, and it's going to be at least another decade before it's close to commodity / unsupported status.
Open source's advantage is not in eating market share (which would take around 20 years, at best). It's in shrinking the size of the market by eliminating license revenue, and reyling mostly on marketing (not a salesforce) to drive subscription revenue. It's unclear if that's a sustainable business model, but it's the one that most vendors seem to be adopting (MySQL, JBoss, RedHat, etc.)
Focus on what's rare in the market, and you will have lots of success.
.NET or Java designer/architect/developer (pick your buzzword) that also understands the telecom industry or pharmaceuticals, but also has deep DBA skills in Oracle and MS SQL Server, and understands TCP/IP deeply (even maybe knows how to administer Cisco routers) is a rarity, and will be compensated handsomely. Why? Most IT failures occur because project members don't understand the business needs, or misuse the database or network, and none of the dev, dba, or network specialists really know how to deal with one another.
For example, the IT job market will always require people with insight, perspective, and an ability to clarify. I don't care if you call these people "managers", "team leads", or "architects", but I think it really just comes down to an ability or talent to map one domain (a business or industry) to technology, without force fitting technology onto the domain.
This talent is needed everywhere: IT development, IT management, infrastructure planning, in software vendor product development, consulting or contracting, etc. IT sorely lacks people with insight and perspective -- a balance of depth and breadth. They have lots of specialists that can't look up from their narrow area, they have generalists that know very little about any one thing, but are good enough with juggling personalities and strengths that they make OK managers. What we need are people that are specialists in several areas, and an ability to synthesize. -- how to apply technology to an industry, and knowing various technology specialities.
For example, a
It's not like any of these topics are particularly hard to learn -- it's just that most people tend not to mix specialities for a variety of religious reasons (developers hate DBAs and vice versa, PHP developers hate Java devs, etc.), and many people are too interested in bits & bytes , thus don't want to look at the broader world outside of technology to understand their industry deeply.
Even in a global talent pool, there will always be a need to attain and grow local talent, for simple logistical reasons (same time zone, same language, same culture ==> easier to plan).
The challenge wtih IT is that there are lots of people that don't really want to be doing this work, there are lots of people that also shouldn't be doing this work (but wound up in the industry by accident), and lots of people so ground into dust by bureaucracy or petty tyrants that they're just retired on the job. You need to have lots of passion and endurance to keep the momentum. Once again, you'll be rewarded for this attitude, because it's so damn rare.
As someone who has used Oracle's support, among others (Cisco, Sun, IBM, Microsoft, BEA), I can say that many of the large players have very good support once you get into Tier 2 or backline. These support professionals are dedicated to customer problems, unlike devs in a smaller org who often have engineering commitments. It's a balance.
I know that Cisco is renowned for their quality supoprt. Oracle has been crappy as of late due to some management and outsourcing mistakes, but had been quite good a few years back in my opinion. BEA's support website won an awared from the support professionals association for one of the "best support websites" last year, if I recall.
I think there's truth that small companies tend to have less bureaucracy and hence it's easier to find people that know what they're doing , but it doesn't follow that large companies don't have similar quality support professionals, or that their processes can be optimized to reach the appropriate person at the right time.
A falsehood is to suggest that open source has anything to do with quality of paid support -- it's more BigCo v. SmallCo tradeoffs.
As I've posted below, I disagree with this. I've owned a Thinkpad T60 and various other Thinkpads over the years, along with Dells, Acers, and several Powerbooks. The aluminum Powerbook 17-inch G4 was the best of them all for durability, maintainable looks, and performance. Every one of these wound up requiring repairs after 2 years of sustained use and travel, but the Powerbook is still chugging along quite well with few noticable scratches, and no notable problems (other than the G4 1.33 getting a bit long in the tooth).
Take the MacBookPro. Pick it up in one hand along an edge. If you can't see the entire damn case flexing, I'll eat my UPS.
Get off your bloody high horse. I'm holding the one I just purchased last week by an edge right now..... Hmm. seems fine to me. (as was the AlBook).
Look, I guess if you like to play laptop frisbee and work in a ditch all day, I can see the desire for ruggedized plastic. But frankly the annodized alumnium has been the best durability/looks combo of a laptop that I've experienced. And I have plenty of data points to compare it to.
I have a lot of Thinkpad-fan friends and their major reason for liking it is the nipple vs. trackpad debate, which frankly seems like a religious issue that will never go away... I admit I've had some shitty trackpads but the Powerbook/Macbooks are quite nice (the Acer's Synaptics pad was the nicest IMHO, but sadly that was 4+ years ago )....
Sorry, I really have to disagree with this.
I've been through a lot of laptops: Thinkpads in the mid through late 1990s, Dell Insipiron 8000 and 9000 series, Dell Latitude D600 and D800, Acers, Powerbook G3, Powerbook G4 titanium and aluminum, and now the MacBook Pro.
Out of all of these, the most durable and problem-free was the 17-inch Powerbook G4 alumnum 1.33 ghz. It still looks great 2.5 years after I purchased it after _heavy_ airline travel, use, and abuse, in many locations, grabbing it via one hand, etc. I've had to replace the power adapter once because it began to split at the end, due to repeated yanking / bending -- that's all. The actual laptop case does not scratch or bend anywhere near as much as the plastic cases of the other laptops. The Titanium G4, FWIW, was rather flimsy and had paint that scratched easily.
Other than the processor whine, which I don't usually hear, the MacBook Pro has the same durable feel and construction of my AlBook G4, and I'm looking forward to many a year with it.