I wouldn't consider XML DBs a special case of OO DBs. OO DBs imply something more about object relationships. The often imply the notion of methods and operators on these objects.
Belive me, there are LOTS of very cool things that you can do when you break the relational model. Is the relational model going away? Hell no. Is XML somehow competing with the relational model. Nope.
I honestly don't see anything XML related being faster then relational for transactional data. However, for knowledge representation or data interchange, hierarchies rock!
I work for a company that has been doing hierarchical DBMSs for years. The company is Applied Technical Systems. We make a database engine called CCM.
XML is a great way for exchanging data, but the term XML databases is very misleading. If the database engine actually stores data in native XML, it's going to be *very* slow. I think the point behind XML is that nobody should really have to care what your backend is as long as you can export reasonable XML. Note that I say reasonable XML. And XML export that simple encodes the rows and fields in a table to XML with <row> and <col> tags is NOT reasonable. It conveys no actual knowledge of the real structure of the data.
Storing XML data in a relation DB can either be a very hard problem or a very easy one. Let me explain.You could look at some XML and define a DB schema for it, not too hard to do. Problem? It's not generic; a human has to re do it each time the XML structure changes. The alternative is to store it all in one big table and index the hell out of it. Problem? It's slow. At that point you aren't using any structure of the XML or the power of relational DBs.
I'm a firm believer that efficient XML storage, querying and retrieval will require a hierarchical database. The problem is that there's several features (bugs IMHO) in XML (and XPath) that, in a way, are throwbacks to relational DBs. IDREFs and the notion of document order particularly bug me.
I ran into these this summer when I was on a team trying to build a XPath and XQuery front end for CCM.
We're gradually seeing the XML world change. Early XML documents were similar to the type mentioned above. They were flat. When you start adding depth the information inherent in the structure of the data becomes apparent. Another thing I'm glad to see the industry move away from is the notion that XML resides in files. Many (if not all) of the early XML parsers made this assumption. It was a pain in the ass to parse from some other source, like a buffer in memory.
Usually 'uptime' is defined by clients being able to access it. If the exploit denies clients access to the service then the server is down. Otherwise, you could get 99.999% by just booting up into the BIOS or firmware and let it sit there.
>Oh, and again, 802.11b just sucks too much power, it is not a Bluetooth killer and Bluetooth is not an 802.11b killer. Simple.
Well...it's NOT that simple.
802.11b has much more behind it, that means mroe R&D, that means less power consumption. As it stands now, the difference between the two in power consumption isn't that much. Sure, it's possible for Bluetooth to use less..maybe. The upshot of this is that would could jsut put 802.11b on your palm.
The other issue is interference. As 802.11b takes off, bluetooth has mroe problems in the RF spectrum. They do interfere to some extent, and I happen to put a hugher value on my home 802.11b network then on cable replacement.
With all that said, I think bluetooth is a kick ass technology. If anything has gone wrong, it's people thinking that 802.11b is going to kill it in the market, as if they were designed for the same problem. This lead to the bluetooth protocol becoming far more complex in someplaces an lagging in others.
I would have liked to see piconets of larger then 8 devices. Sure, some non technical guy wrote a 'spec' to allow a device to route between two pico nets, but it's Evil(tm).
Look at this link:
http://www.washington.edu/hdtv/nab/press.html. The University of Washington sent 4 HD streams down to Las Vegas. In LV, all the video switching, chroma key, and digital fx were added. The resulting stream was sent back to Seattle for broadcast. Each stream was in the 200Mbps range. Nice.
that science and engineering aren't a perfectly directed activity. You don't just magically 'build' Viagra in day. You don't just build the system and do a final test. You bite off pieces. When will they learn??!?!?!
Realize that universities take a large amount off the top of any research grant. 25-30% of the grant going to the university is not unheard of.
Corporations *are* paying for the research. This IMHO is a very good thing. Schools get much needed funding and the chance to dig into the latest areas of research. This ultimatly helps the students.
--Justin
(An undergrad at U of WA involved in research)
The issue is if you accidently overwrite the boot block. If you do that the only way to fix it is to flash via the JTAG port. Has nothing to do with the boot loader itself.
I have worked with the Intrinsyc board. It's pretty cool, nicely built. Certainly, a real USB connector would be nice.
With that said, their support was VERY poor. The main contact had one response to all questions: "Why would you want to do that?"
Also, watch out for the flash. It is VERY easy to overwrite the boot block. If you do this then you will have a paperweight unless you build/buy a JTAG adapter and hack around a bit.
If you want cool hardware, get an iPAQ and throw Linux on it.
Why does person/group A always try to force their opinion on person/group B??? This has caused most wars (both virtual and real) It's also a HUGE waste of resources.
Who said that programming contests were *trying* to replicate real life problems. They are contests, they need problems that are easily judged.
I've competed at the ACM ICPC World finals, the teams that do well there are top notch upstairs. Not only can they code quickly, but they can do so elegantly. In many cases that is indead the key to solving an ACM problem.
If one does their research, you'll notice that there are several longer term contests.
I don't think it changes anything. Its no different then basing a job offer on a 60min interview.
I'm a CompE student at U of Washington.
This distinction really depends on school. Here the CompE major is part of the Computer Science and Engineering Department. At other schools It's part of the EE department.
There is certainly a little more hardware involved in CompE, in our case it's 2 EE classes and some digital design courses.
The major is broken up into two tracks, hardware and software. The hardware track is more digital design (VLSI, etc) oriented. The software track has a little more focus on the notion of 'software engineering' and embeded systems.
The cool thing here is that there is very little actual difference between the majors. I took the CompE software track because I like embeded systems. Basically UW CompE pretty much equals CS some extra stuff.
The company I work for (Applied Technical Systems, www.apptechsys.com) runs an awesome intern program for HS students. I was a intern there my senior year of HS(4 years ago) and we currently have 4 or 5(depends on classes/sports seasons:)) working. The entire company is around 20 full time and a few assorted part time college students(I'm one) plus the HS interns. One of our most recent intern hires is the author of gnapster. Most of them work with us full time during the summer.
There is certainly some easy/simple work that we have them do, but most comes in the form of higher level projects. Some even get to go on travel to meet(impress) customers!
A few projects:
Prototypes of data-driven web sites
Building those same sites:)
Our intranet
SysAdmin stuff
Client/Server and database engine programming
New language bindings for our database engine
More importantly, often they 'own' a particular project. Also, we feel that school is far more important then how many hours they put in, etc. If they can't make it in, we just ask they they call or e-mail to let us know.
Not to mention that the pay isn't all that bad either!
So all binary only drivers could be *required* to be GPLed? Very fuzzy(scary) indeed. What about applications built on top of RTLinux? They are pretty much linked into the kernel.....
Re:This has been done
on
Space Diving
·
· Score: 1
I think this was a US Air Force project caleld "Project Manhigh." They pioniered the droug chute that slows the diver down so the force of the main chute opening doesn't kill the diver. They also used a mixed gass atmosphere enviroment instead of the pure oxygen that NASA was using and later changes after they lost two astronauts on the pad. See: http://www.flatoday.com/space/explore/stories/1998 b/081998a.htm
I agree. Intel isn't perfect. And face it, AMD isn't perfect. Take any college level computer arch class. Intel made many design tradeoffs, it's called engineering.
This guy would be well suited to look at RISC procs in more detail. They impose far more true restrictions on instruction ordering. As the RISC people found out YEARS ago, the compiler *really* makes a difference. Transmeta and Intel(IA-64) are rediscovering the same thing.
Even if he is 100% correct, he looses bigtime credibility points for the bias. It left doubts in my mind.
Slashdot Mirror
I wouldn't consider XML DBs a special case of OO DBs. OO DBs imply something more about object relationships. The often imply the notion of methods and operators on these objects.
Belive me, there are LOTS of very cool things that you can do when you break the relational model. Is the relational model going away? Hell no. Is XML somehow competing with the relational model. Nope.
I honestly don't see anything XML related being faster then relational for transactional data. However, for knowledge representation or data interchange, hierarchies rock!
I work for a company that has been doing hierarchical DBMSs for years. The company is Applied Technical Systems. We make a database engine called CCM.
XML is a great way for exchanging data, but the term XML databases is very misleading. If the database engine actually stores data in native XML, it's going to be *very* slow. I think the point behind XML is that nobody should really have to care what your backend is as long as you can export reasonable XML. Note that I say reasonable XML. And XML export that simple encodes the rows and fields in a table to XML with <row> and <col> tags is NOT reasonable. It conveys no actual knowledge of the real structure of the data.
Storing XML data in a relation DB can either be a very hard problem or a very easy one. Let me explain.You could look at some XML and define a DB schema for it, not too hard to do. Problem? It's not generic; a human has to re do it each time the XML structure changes. The alternative is to store it all in one big table and index the hell out of it. Problem? It's slow. At that point you aren't using any structure of the XML or the power of relational DBs.
I'm a firm believer that efficient XML storage, querying and retrieval will require a hierarchical database. The problem is that there's several features (bugs IMHO) in XML (and XPath) that, in a way, are throwbacks to relational DBs. IDREFs and the notion of document order particularly bug me. I ran into these this summer when I was on a team trying to build a XPath and XQuery front end for CCM.
We're gradually seeing the XML world change. Early XML documents were similar to the type mentioned above. They were flat. When you start adding depth the information inherent in the structure of the data becomes apparent. Another thing I'm glad to see the industry move away from is the notion that XML resides in files. Many (if not all) of the early XML parsers made this assumption. It was a pain in the ass to parse from some other source, like a buffer in memory.
They consume less heat?!?! Cool!!
LOL
Usually 'uptime' is defined by clients being able to access it. If the exploit denies clients access to the service then the server is down. Otherwise, you could get 99.999% by just booting up into the BIOS or firmware and let it sit there.
This is the same thing that any major, secure install has been doing from day 1.
However, it is good to see widespead use of these techniques. Maybe it'll help those less secure installs:)
>Oh, and again, 802.11b just sucks too much power, it is not a Bluetooth killer and Bluetooth is not an 802.11b killer. Simple.
Well...it's NOT that simple.
802.11b has much more behind it, that means mroe R&D, that means less power consumption. As it stands now, the difference between the two in power consumption isn't that much. Sure, it's possible for Bluetooth to use less..maybe. The upshot of this is that would could jsut put 802.11b on your palm.
The other issue is interference. As 802.11b takes off, bluetooth has mroe problems in the RF spectrum. They do interfere to some extent, and I happen to put a hugher value on my home 802.11b network then on cable replacement.
With all that said, I think bluetooth is a kick ass technology. If anything has gone wrong, it's people thinking that 802.11b is going to kill it in the market, as if they were designed for the same problem. This lead to the bluetooth protocol becoming far more complex in someplaces an lagging in others.
I would have liked to see piconets of larger then 8 devices. Sure, some non technical guy wrote a 'spec' to allow a device to route between two pico nets, but it's Evil(tm).
Look at this link: http://www.washington.edu/hdtv/nab/press.html. The University of Washington sent 4 HD streams down to Las Vegas. In LV, all the video switching, chroma key, and digital fx were added. The resulting stream was sent back to Seattle for broadcast. Each stream was in the 200Mbps range. Nice.
that science and engineering aren't a perfectly directed activity. You don't just magically 'build' Viagra in day. You don't just build the system and do a final test. You bite off pieces. When will they learn??!?!?!
Realize that universities take a large amount off the top of any research grant. 25-30% of the grant going to the university is not unheard of.
Corporations *are* paying for the research. This IMHO is a very good thing. Schools get much needed funding and the chance to dig into the latest areas of research. This ultimatly helps the students.
--Justin
(An undergrad at U of WA involved in research)
The issue is if you accidently overwrite the boot block. If you do that the only way to fix it is to flash via the JTAG port. Has nothing to do with the boot loader itself.
And ours bloomed last year too:)
Does it actually include CE? Or, do you have to get it from MS (i.e. Platform builder)?
I have worked with the Intrinsyc board. It's pretty cool, nicely built. Certainly, a real USB connector would be nice.
With that said, their support was VERY poor. The main contact had one response to all questions: "Why would you want to do that?"
Also, watch out for the flash. It is VERY easy to overwrite the boot block. If you do this then you will have a paperweight unless you build/buy a JTAG adapter and hack around a bit.
If you want cool hardware, get an iPAQ and throw Linux on it.
My code never looked good...even the first time around:) But I bet the most of the people there can write good code.
Why does person/group A always try to force their opinion on person/group B??? This has caused most wars (both virtual and real) It's also a HUGE waste of resources.
Who said that programming contests were *trying* to replicate real life problems. They are contests, they need problems that are easily judged.
I've competed at the ACM ICPC World finals, the teams that do well there are top notch upstairs. Not only can they code quickly, but they can do so elegantly. In many cases that is indead the key to solving an ACM problem.
If one does their research, you'll notice that there are several longer term contests.
I don't think it changes anything. Its no different then basing a job offer on a 60min interview.
I really like the MasterCard add that was at the bottom of the page when I viewed it. It's a LinkExchange banner:)
I'm a CompE student at U of Washington.
This distinction really depends on school. Here the CompE major is part of the Computer Science and Engineering Department. At other schools It's part of the EE department.
There is certainly a little more hardware involved in CompE, in our case it's 2 EE classes and some digital design courses.
The major is broken up into two tracks, hardware and software. The hardware track is more digital design (VLSI, etc) oriented. The software track has a little more focus on the notion of 'software engineering' and embeded systems.
The cool thing here is that there is very little actual difference between the majors. I took the CompE software track because I like embeded systems. Basically UW CompE pretty much equals CS some extra stuff.
There is certainly some easy/simple work that we have them do, but most comes in the form of higher level projects. Some even get to go on travel to meet(impress) customers!
A few projects:
- Prototypes of data-driven web sites
- Building those same sites:)
- Our intranet
- SysAdmin stuff
- Client/Server and database engine programming
- New language bindings for our database engine
More importantly, often they 'own' a particular project. Also, we feel that school is far more important then how many hours they put in, etc. If they can't make it in, we just ask they they call or e-mail to let us know. Not to mention that the pay isn't all that bad either!So all binary only drivers could be *required* to be GPLed? Very fuzzy(scary) indeed. What about applications built on top of RTLinux? They are pretty much linked into the kernel.....
I think this was a US Air Force project caleld "Project Manhigh." They pioniered the droug chute that slows the diver down so the force of the main chute opening doesn't kill the diver. They also used a mixed gass atmosphere enviroment instead of the pure oxygen that NASA was using and later changes after they lost two astronauts on the pad. See: http://www.flatoday.com/space/explore/stories/1998 b/081998a.htm
Couldn't agree more.
I agree. Intel isn't perfect. And face it, AMD isn't perfect. Take any college level computer arch class. Intel made many design tradeoffs, it's called engineering.
This guy would be well suited to look at RISC procs in more detail. They impose far more true restrictions on instruction ordering. As the RISC people found out YEARS ago, the compiler *really* makes a difference. Transmeta and Intel(IA-64) are rediscovering the same thing.
Even if he is 100% correct, he looses bigtime credibility points for the bias. It left doubts in my mind.
This should make things better:)