I would be spooked by an already formatted drive (don't they ship blank?) According to my Solaris box, yes, they do. At least, I've never been able to just install a new drive and do anything with it before I partitioned it and laid down a file system.
Do you really WANT to be carrying around a camera, a phone, a PDA, and a laptop? No. All I want is a goddamn phone. I carry a pen and a small notebook for jotting down notes (which I can do it without having to interrupt the call to enter something on the phone), and I don't need a camera or a laptop. Actually, I just bought a Bluetooth headset, because I hate trying to hold my skinny little phone against my ear with my shoulder while I write. I do use my phone's calendar feature sometimes, but I certainly wouldn't miss it if I switched to a phone that didn't have one.
I also enjoy listening to my iPod while I mow the lawn. I don't want my music interrupted by some stupid ringtone, and I'm sure as hell not going to shut down the mower and stand out there in the middle of the lawn talking on my phone. I just want to leave the phone in the house and listen to some tunes while I mindlessly push the mower around. I don't need to be converged on every minute of every day.
I've been told, though I've not had it confirmed ( I keep hoping to run across it somewhere) that Germany *had* to use hydrogen Actually, I'm wondering why everybody's still so dead-set on using helium for lifting. It's twice as dense as hydrogen (0.18 kg/m^3 vs. 0.09 kg/m^3) and far less abundant. Sure hydrogen burns if you light it, but so does gasoline and that doesn't stop people from carrying gallons of it around wherever they go[0]. Not to mention that hydrogen (H2) atoms are larger than helium atoms, and therefore don't require exotic envelope materials to prevent the gas from escaping.
[0] Fun fact: more people were injured due to gasoline burns than hydrogen burns when the Hindenburg went up in flames.
If its so easy to parse, why are the libraries that parse it such a pain to use? Probably because, as someone else pointed out already, XMl is intended to express structured data. Therefore, it's best to have some idea what the structure is before you start parsing it. Sure, you can just grab a stream and start pulling tags out of it, but then you have to keep track of what tag you're working with, make sure things are well-formed and a bunch of other stuff that gets in the way of just grabbing the data you went in for in the first place.
OTOH, if you've got the schema for the XMl you're parsing, then you can use something like JAXB to generate a bunch of classes that represent all the elements, then just create an Unmarshaller, pass it your XML, and it passes you back a reference to the class that represents the root element and you can traverse it, grab the data, frob the figures, then create a Marshaller and hand it the root element and have it spit out a new XML document. Painless & brainless, and works really well for things like web services that publish their schemas.
I'm not sure what the memory usage is, I certainly wouldn't bet that it's negligible, but it's probably not outrageous, either. Predictable is often just as good as efficient, since at least you know what to expect.
when I did DB stuff, it seemed common that I wanted a single cell in a table to contain 0 to potentially "lots" of values where each one was indexed Something like a single DB column that has an array data type? This is generally used in data warehousing situations to provide access to aggregate details (e.g., you have a row that contains the total of all sales for a quarter, but there's a field in there that contains all the sales by region). It's also generally wished for by people who don't understand relational concepts and want to put all the data they need in one table so they don't have to do any joins.
I'd prefer to believe you just did a lot of data warehouse work...;)
the bizarre contortions required to get between an object and its fields at runtime (in SXM's case, wrapping all fields in properties and using a runtime-generated subclass that overrides the setters and getters to monitor the transaction) feel more unnatural to me than SSA form. Isn't that roughly what Ruby does, invoking an implicit accessor function if one hasn't been explicitly supplied? And I know that some commercial Java products use reflection and bytecode injectors to intercept attribute accesses, which requires no (manual) modification of the baseline code.
I'm not familiar with SXM, but based on what I've seen elsewhere it doesn't sound like it uses a terribly unworkable approach. That said, I have more of a desire to play with Erlang than SXM or other transactional memory approaches.
Now, $230 is supposed to get you 256MB / 2GB And wasn't there supposed to be a version with a 10" screen? I've seen the prices hike up, but I haven't seen a 10" screen mentioned since the first articles came out. I was all set to buy one (hell, for the $299 [IIRC] they were quoting for it, I'd have bought two!), and I'd probably spend up to US$350 on it, but they seem to have quietly dropped that model. Another victim of the "Specifications subject to change without notice" clause, I guess.
perhaps you have been in a position where you are only sharing documents with other folks internal to your company that are on the same version? Heh. I worked at a company that had done that, but then they started growing quickly. In order to expedite bringing new hires on board, they started ordering PCs with Office installed. Things were fine until MS released Office 97, and new machines started showing up with that installed. I spent a couple of days telling a cow-orker that her changes were corrupting our shared documents. She had no problems opening them, but I was getting errors. Finally I tried talking her through saving the document in some other format, and when she read off the formats she had available and "Word 95" appeared on the list, the light finally went on.
And as far as users Solaris is late to the party as well. Apple got there before it. ??? You mean desktop users? I seriously doubt your typical Mac user spends much time at the command line, or even knows much about Unix. The default environment for Solaris 10/OpenSolaris is GNOME, so Windows users at least have some hope of figuring out how to launch their browser and e-mail client. This makes it pretty much even with Linux.
I think OpenSolaris will see its greatest adoption in the SME and hosting segments. Hosting companies love Linux because it's free-as-in-beer, SMEs love it because it's more efficient than Windows, so they can re-purpose older hardware as back-room servers, or try offering their own web-based services at low risk. If companies had the choice of running what college kids run, or running the software that powers Sun servers, which do you think they'd choose? Technical issues aside, I think that name recognition is going to drive some significant uptake for OpenSolaris. Linux has lots of mindshare, so I doubt it'll suffer overmuch, but I wouldn't be surprised if OpenSolaris showed stronger growth.
the greatest strength of Linux is that most of its codebase is understandable Oh, definitely. It's right up there with OpenVMS. And we all know how much market penetration that has...
Oh yeah fun hint: Jythons XML-RPC server + Your Java monstrosity of choice = xml-rpc API for your app in under a page of code Hope it did that last year, because that's about the last time anybody developed anything using XML-RPC in Java. Wake me when they support basic WS-I functionality. Oh, and adding a WS API to your app in Java only requires you to write this: @WebService() public class WebServiceAPI {
@WebMethod
public String callSomeAppFunction(@WebParam(name='param1') final String param1,
@WebParam(name='param2') final String param2) {
return someAppFunction(param1, param2);
} }
Oh, and to make that an XML-RPC API, just add the line: @SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=ParameterStyle.WRAPPED)
the JRE system libraries will be memory resident regardless of whether a Java application is actually used. This is not an optimal solution Dunno, seems to work for Microsoft. I know when I fire up XP, I can't do anything useful until 2-3 minutes after I log in (and this is after I spend 2-3 minutes waiting until I can log in), because "svchost" is busy loading the.NET runtime.
At this point, I'm not really sure what can be done. People want more conveniences from software, and due to software engineering's penchant for abstracting everything, we wind up with interfaces to subsystems that call dynamically-loaded libraries that invoke kernel routines that shuffle buffers to drivers that don't even control the hardware, but instead instruct another abstraction layer. It's no wonder software is slow, the wonder is that it works at all.
the real solution is to reduce the enormous size of the JRE libraries If you split up the JRE libraries, all it means is that instead of having to load one huge library, now you get to load a bunch of interdependent libraries. While there probably is some refactoring that could be done, I doubt you'll really see that much of an improvement (is it really quicker to load five 100K libraries than one 500K one?).
that $450/month enables him to make $10K+/month (if he is competent.) I dunno, if he moved his business to a new location and didn't do the (relatively minor) due diligence to make sure he could continue to operate... Of course, web design and common sense don't always go hand in hand, but business sense and common sense seem to play well together most of the time.
I, for one, can't think of a single upside of "Software as Service" Oh, heavens, where to start...
No more installers sticking stuff in your registry
Upgrades involve changing your bookmark to point from "host.com/someApp/1.0/login" to "host.com/someApp/1.1/login"
Installing another copy of the app to use at home is as simple as mailing the URL to your personal e-mail account
I'm not really a big proponent of "software as service" (especially for desktop productivity apps), but I can see it has a definite niche for some large-scale apps (see the rise of salesforce.com), especially those that foster communication among a distributed work force.
I think there really needs to be a legal framework for people (end users) who own software You don't own software, you license it. Unless you contracted a company to write something for you and you explicitly retained the rights (and the source).
Next, growth IMHO for certain industries like the game industry is being held back by not subsidizing the cost of some kind of mid-range performance standard graphics *for everyone*. You can get a DX10 graphics card for US$100. Or are you still using an AGP motherboard?
I find it ironic that companies like Nintendo, Sony, and MS can subsidize their consoles, but when it comes to the PC, MS just sit's there. MS doesn't make PCs.
I think one of the big reasons PC gaming is flagging was in large part due to the incessant march of the graphics card industry. Are you suggesting that game companies can't handle the increased power of new graphics cards?
Starcraft and Diablo 1 & 2 were both 2D games, it makes sense that these games got as widespread as they did because they'd run everywhere. So, basically you just want a line of Cheap Bastard(TM) games? Why not just haunt the used games stores? I'm sure you can find something there that'll run on your 850MHz P-III.
Who said anything about network traffic? I said that buffering data from disk helped to minimize playback gaps. It also should help network traffic from a standpoint of decreasing the number of interrupts that need to be serviced, but I can't remember the last time I saw a machine that was so overloaded it couldn't keep up with network traffic (unless it couldn't respond because it was waiting for data from the disk...)
I'd also raise an eyebrow over the assertion that "performance is predictable if only one app is using the NIC". Network performance is affected by so many factors it's almost impossible to predict, and the great majority of bandwidth throttling is due to network latency, not the number of apps using the NIC on your machine. That said, one method that used to be popular was the buffer queue, where you kept a queue of buffers and tried to keep them filled. When your app needed more data, you passed it a pointer to one of the buffers and marked it as "in use". The rest were either "new" (meaning they contained data your program hadn't read yet) or "free", meaning they were available for filling with new data. Your read routine tried to read data until all the buffers were filled, then slept until some number of buffers became free. The great thing about this scheme is the fact that if network performance is bad, you can increase the number of buffers in your queue and try to keep more data on hand. If performance picks up, you can release the buffers as they become free. Of course, no amount of buffering will solve all I/O problems, but it certainly beats throttling the network just because the disk is busy...
Cut and crimp positive, negative and ground, fight with heavy gauge wire, find suitable ground points, or make your own if you have to... Nonsense. You just run the wires over to the buss bars that run between the racks, drill a new hold for each one and bolt it up. No muss, no fuss, and your wires are easy to manage. Plus, open buss bars hold serious comic potential if one of your cow-orkers likes to wear a big key ring on their belt...
I can see there being a small section that was accidentally shot once, but the entire length of a kilometer? That's not just a couple stray shots. What the article neglects to mention is that they were shooting at a backhoe. They were actually defending the cable. Unfortunately, backhoes are a lot harder to hit when you've had that much cough syrup...
You can see why they would reserve some hard drive bandwidth though; as the GP said it is to provide skip-free audio Back in my day (and that was early last Thursday), we had this thing called "buffering", where you actually read more data than you needed, and then when you needed more you got if from the buffer instead of going all the way back out to the disk. Some of us actually used two buffers, and filled one from disk while reading data from the other. This gave us a fair amount of isolation from I/O scheduling and transfer delays. Guess that just shows what fools we were, instead of coming up with a fancy bandwidth reservation scheme to regulate everything.
Hand me down my silly-scope, Maw, the danged computer's a-runnin' slow agin...
this is the newer version, so I'm sure the interface has been improved and brought up to date Yeah, but is it backwards-compatible? I've still got debt from when I used Red Cent 5.1, with the 2.0.36 exchange rate! Will they at least provide a utility to convert all my old debt? If not, then forget it.
Slashdot Mirror
I also enjoy listening to my iPod while I mow the lawn. I don't want my music interrupted by some stupid ringtone, and I'm sure as hell not going to shut down the mower and stand out there in the middle of the lawn talking on my phone. I just want to leave the phone in the house and listen to some tunes while I mindlessly push the mower around. I don't need to be converged on every minute of every day.
Heh. My first thought was "Oh, mashups....how....last month! Could I have some fresh hype, please, this one seems to have gone cold..."
<shrug/>
[0] Fun fact: more people were injured due to gasoline burns than hydrogen burns when the Hindenburg went up in flames.
OTOH, if you've got the schema for the XMl you're parsing, then you can use something like JAXB to generate a bunch of classes that represent all the elements, then just create an Unmarshaller, pass it your XML, and it passes you back a reference to the class that represents the root element and you can traverse it, grab the data, frob the figures, then create a Marshaller and hand it the root element and have it spit out a new XML document. Painless & brainless, and works really well for things like web services that publish their schemas.
I'm not sure what the memory usage is, I certainly wouldn't bet that it's negligible, but it's probably not outrageous, either. Predictable is often just as good as efficient, since at least you know what to expect.
I'd prefer to believe you just did a lot of data warehouse work...
I'm not familiar with SXM, but based on what I've seen elsewhere it doesn't sound like it uses a terribly unworkable approach. That said, I have more of a desire to play with Erlang than SXM or other transactional memory approaches.
I think OpenSolaris will see its greatest adoption in the SME and hosting segments. Hosting companies love Linux because it's free-as-in-beer, SMEs love it because it's more efficient than Windows, so they can re-purpose older hardware as back-room servers, or try offering their own web-based services at low risk. If companies had the choice of running what college kids run, or running the software that powers Sun servers, which do you think they'd choose? Technical issues aside, I think that name recognition is going to drive some significant uptake for OpenSolaris. Linux has lots of mindshare, so I doubt it'll suffer overmuch, but I wouldn't be surprised if OpenSolaris showed stronger growth. the greatest strength of Linux is that most of its codebase is understandable Oh, definitely. It's right up there with OpenVMS. And we all know how much market penetration that has...
@WebService()
public class WebServiceAPI {
@WebMethod
public String callSomeAppFunction(@WebParam(name='param1') final String param1,
@WebParam(name='param2') final String param2) {
return someAppFunction(param1, param2);
}
}
Oh, and to make that an XML-RPC API, just add the line:
@SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=ParameterStyle.WRAPPED)
right after the "@WebService" annotation.
At this point, I'm not really sure what can be done. People want more conveniences from software, and due to software engineering's penchant for abstracting everything, we wind up with interfaces to subsystems that call dynamically-loaded libraries that invoke kernel routines that shuffle buffers to drivers that don't even control the hardware, but instead instruct another abstraction layer. It's no wonder software is slow, the wonder is that it works at all. the real solution is to reduce the enormous size of the JRE libraries If you split up the JRE libraries, all it means is that instead of having to load one huge library, now you get to load a bunch of interdependent libraries. While there probably is some refactoring that could be done, I doubt you'll really see that much of an improvement (is it really quicker to load five 100K libraries than one 500K one?).
I'm not really a big proponent of "software as service" (especially for desktop productivity apps), but I can see it has a definite niche for some large-scale apps (see the rise of salesforce.com), especially those that foster communication among a distributed work force.
"Paging Fuckup Fairy, Fuckup Fairy to $WORK['lukas84'], please..."
You should be receiving your intermittent, multi-symptom, unsupported-configuration-related H/W failure in...3...2...1...
Who said anything about network traffic? I said that buffering data from disk helped to minimize playback gaps. It also should help network traffic from a standpoint of decreasing the number of interrupts that need to be serviced, but I can't remember the last time I saw a machine that was so overloaded it couldn't keep up with network traffic (unless it couldn't respond because it was waiting for data from the disk...)
I'd also raise an eyebrow over the assertion that "performance is predictable if only one app is using the NIC". Network performance is affected by so many factors it's almost impossible to predict, and the great majority of bandwidth throttling is due to network latency, not the number of apps using the NIC on your machine. That said, one method that used to be popular was the buffer queue, where you kept a queue of buffers and tried to keep them filled. When your app needed more data, you passed it a pointer to one of the buffers and marked it as "in use". The rest were either "new" (meaning they contained data your program hadn't read yet) or "free", meaning they were available for filling with new data. Your read routine tried to read data until all the buffers were filled, then slept until some number of buffers became free. The great thing about this scheme is the fact that if network performance is bad, you can increase the number of buffers in your queue and try to keep more data on hand. If performance picks up, you can release the buffers as they become free. Of course, no amount of buffering will solve all I/O problems, but it certainly beats throttling the network just because the disk is busy...
Hand me down my silly-scope, Maw, the danged computer's a-runnin' slow agin...
FTTT — fiber to the toilet.
Or like the Lorner-Porsche models from the early 1900s. Among the first (if not the first) examples of both hybrid and four-wheel drive!