Re:Ok, so HURD is a microkernal os...
on
Hurd: H2 CD Images
·
· Score: 2
This is actually not entirely accurate. If you look a bit more closely at (especially) the Cocoa and (to a lesser extent) the Carbon APIs, both rely on the BSD layer for very important tasks, such as file system access (a recent technote mentioned the fact that since Carbon file-system access is mapped to BSD calls, certain things like exclusive-write access doesn't actually work).
the quality of the audio coming in over your TV is as good as any CD
This is generally not true at all. The audio tracks in the music videos are never identical to the album track. In fact, often, their quality is greatly reduced for the simple fact that almost everything that's destined to play on a TV has its dynamic range hugely compressed. This means that the volume difference between the 'quiet' and 'loud' bits are reduced. This is because most people listen to music videos on 20" TVs with 2" speakers of terrible quality. The music tends to sound better on these speakers if its dynamic range has been compressed. It does, however, kill a portion of the 'feel' of the original music.
In addition, the original video/audio feed is an analog stream. It is then digitized by your cable providor and sent to you. This may eventually change as more channels are natively digital, but this is quite a few years in the future.
Fantastic. This person re-iterates exactly the same URL link that was in the story (http://www.pdos.lcs.mit.edu/exo.html) and it gets moderated up to 4 as 'insightful'? Seriously, if you're going to moderate a story, the least you can do is click on the link so you know what you're moderating.
This is completely untrue. Objective C++ was included in MacOS 10.1. I'm using it as we speak. It allows you to mix Objective-C and C++ code freely in a single source code file. It works just as it should. It takes much longer to compile, though. Something about pre-processed headers, I think.
Wow. I'd hope for your sake that you're not the one negotiating with your internet providor. I've seen RETAIL bandwidth go for $2/gig in the US. Wholesale goes down lower than $1. At $2/gig, that's about $0.0019 per meg. That's a factor of 20-40x LESS than what your company is paying. I hope for your company's sake that you misplaced a decimal place somewhere.
I suspect in this case, the Trademark of "Coca Cola", as well as the logo, image, colors, etc, is owned by one company and licenced to the other.
But yes, your point is valid. Unless TLDs are split up along exactly the same lines as trademarks are (by the market segment the company is involved in) it is a losing proposition to pretend that one and only one company can own a single trademark.
Hmm... Maybe try the -ansi flag in gcc? In ANSI mode, it will error on any gcc-specific code.
Re:Just like blaming Alfred Nobel for Dynamite (18
on
Blaming Encryption
·
· Score: 2
The fact of the matter is, people DID blame Nobel, and he did feel guilty for creating dynamite. For this reason, he died alone and friendless, though mighty rich. Most see the Nobel Prize as being his way of buying himself a good name in the history books.
Avoiding preemptive multitasking in high performance single-processor programming is a good idea, period.
Why?
Threading is not 'free'. It comes at a cost in context switches that in simple desktop applications is not noticable, but becomes quite noticable once you're doing a game. In addition, it's impossible to have fine control over the scheduling of preemptive threads. In fact, by definition, you don't have control over it, because it's preemptive. I imagine this can cause serious timing issues for something like sound.
The Carbon API is NOT a C++ API. It is purely a C API. Actually, I think it's still availible as a Pascal API, too, which was the language of choice for several years after the introduction of the Mac.
There are several C++ frameworks availible for Carbon. Powerplant, included (with source) with Codewarrior is one, MacApp, from Apple, is another.
The Finder is written using Powerplant, but does not take advantage of the new, more efficient event model availible in Carbon.
The differences between the two 'styles' of Carbon applications are that one style can work in OSX and OS8/9 with a single binary file, and the latter is in the native OSX executable format (Mach-O) which allows it to be linked with unix libraries and use lower level mach kernel services, and direct Quartz API calls.
so let's say each employee costs 100k$ a year (may be higher, but not much lower). So, for 1M$ you get 100 SuSE employees for one year.
Uh... Try again:
$100k / $1M = -10- employees, not 100.
So, assuming your estimate of 1000 employees (which I think is high), that gives them enough cash to pay their employees for 5.4 months, not 4.5 years.
I hate to add to an obviously silly conversation, but you state that Be could not run BeOS on the new G3 Macs because Apple would not release the specs for the new hardware.
Good theory. And it is what Be said.
Do you know how long it took for the PPC Linux developers to get the Linux kernel running on the new G3 machine? About 2 weeks. How many people work on the PPC specific parts of the Linux kernel? About 2 or 3. I can only guess how many software engineers worked at Be at the time, but I imagine more than 2 or 3. So, how stupid do you think people are? Be didn't get BeOS running on the G3 because -THEY DIDN'T WANT TO- just as Elwood said in a parent post to this. The fact that they lied and whined that it was Apple's fault made me lose a great deal of respect for them.
I'd also like to point out that Apple is a HARDWARE VENDER. Do you think Apple makes money selling MacOS X for err, $89 or so? Of course not. It's a loss-leader to get people to buy their hardware which has a higher markup than most consumer PC hardware. People have been talking for years about how Apple should give up on hardware and moving to software. It won't happen. Apple losing control over their hardware platform would greatly reduce the added value that their products give over consumer PCs.
I saw a similar system (not exactly the same one) on TV used to put out one of the oil well fires in Kuwait. The system I saw was basically a large jet engine placed behind the stream of a large water hose. This was a fire that other methods had failed to bring under control for several days. They put the machine about 60 or 70 yards from the fire, turned it on, and within 5-7 seconds, the fire was out.
It got me thinking about why they don't use a system like this in conventional fires. I then realized that such a system would be increadibly destructive to a typical building, probably doing more damage than the fire would. (Imagine being sprayed with water travelling at several hundred mph).
I was also very hopeful when I first read this, but I still thought it was absolutely necessary for me to send in a thought-through email, as I urge EVERY Canadian here to do.
Go to http://strategis.ic.gc.ca/SSG/rp01099e.html (same link as parent message) and read particularly section 4.2.
Next, go to http://strategis.ic.gc.ca/SSG/rp01100e.html and read through it, and then send email to copyright-droitdauteur@ic.gc.ca
Please note that the email link on that page DOES NOT WORK (it links to the wrong email address), though the text of the link is correct.
If you are a Canadian computer professional, this is IMPORTANT. It doesn't seem like a helpless situation, either, as you will see after you read that paper (or the parent message for the highlights). Send an email and soon!
Just think, if we can keep Canada a friendly place for programmers to work, we can possibly end, or even reverse the brain-drain that's been going on for here for years and years.
Another good speculation I heard was that licencing issues relating to DVD software forced Apple to reduce the possibility of reverse-engineering the DVD playback software somehow, since MacOS X software is more hackable than earlier versions, since any program can be executed within gdb.
I'm not really sure why real-time kernel issues would factor into the performance, since they managed to port Quicktime over (though, granted, it's slower than it was in OS9).
The new PowerMacs were significant improvements over the old ones, but nothing to make me run over to the store and replace my dual G4/450 straight away. The 733 is now at the bottom of the line, which is a nice bump from the older 466-odd models. The 867 is also nice but less than one would hope. But what's with dual 800s? Why not dual 867s? Surely availability can't be a major problem with the 867s in the mainstream of the line.
How about price? If you've ever seen bulk pricing for CPUs, you'll see that the price difference between different speeds increases exponentially. I wouldn't be surprised if the 877 mhz CPU costs Apple 50% more than the 800 mhz CPU.
Assuming the 800 costs $100 (Apple's cost), the 877 would cost around $150 each, but 2 800s would only cost $200, instead of $300 for 2 877s.
I think this is totally reasonable and definately smart for Apple. For people that can take advantage of the dual processors, the 77 mhz speed increase would be utterly overwhelmed by the speed bonus of the extra CPU.
What interested me was that the last the that Apple sold dual CPU machines (the 450), they positioned them, price-wise, BENEATH the 500mhz, single-CPU model.
Well, what you're implying here is that we have the ability to create a propulsion system where only a small fraction of the weight of the payload (most of it would be distributed to the power grid after it lands, presumably, only a small amount sending it back up again) would be fuel.
If we had ANY way of producing energy densities like that in a useful fuel, don't you think we'd be using them to send craft up into space right now?
Of course, I'm assuming that the mass of the payload would not change significantly in the loading/unloading process of the energy. That holds for almost anything I can think of.
While I'm not entirely happy with what Apple has done with their registration system, it's also entirely optional. If you're on broadband, simply unplug your machine from your network while you fill out your registration. It then tells you that you can send it later if you want to once you get online, but it doesn't enforce anything.
Also, may I point out:
--Apple Doesn't Require Serial Numbers For MacOS X!-- (It does for OSX Server, though)
I think that kinda beats out a small annoyance with the registration.
Well, thinking as an 'anarchist' might, I would simply swap a 240 VAC line for a high-powered laser if they switched to an optical connection. Voltage spikes are to be expected, but who's going to protect from an optical burst?:-)
This reminds me of the currently popular theory of how life arose, by simply taking constituant elements, heating them up and zapping them with lightning until they form amino acids and eventually proteins.
My theory, however, involves a freak accident involving a cage full of monkeys, a box of hand-held hole-punchers, a large stack of stiff paper and a punchcard reader.
I've written several dynamic web sites using mySQL, JSP and servlets and this is what I did:
Stored the database internally in UTF-8 format and accessed it using unicode from the servlets.
Stored and served the HTML and JSP files in Shift-JIS format. As long as you tell the servlet that a JSP file is in shift-jis, any characters you write to the document as it's being processed will be converted automatically to shift-jis.
Because HTML forms are stupid and don't support (by default) character sets, you have to assume that the form will be sent back in the same character set the file was sent in. In Java, this meant telling the form handler to interpret the bytes as Shift-JIS which automatically converted them back into unicode, which would let me handle the form data in a uniform manner (1 character is 1 character, even its UTF-8 representation is more than one byte) and easily store it in the database in UTF-8.
As far as I knew, Python supported unicode strings, which would allow this type of handling. I recommend storing your database in some sort of native unicode format, which should make this fairly seamless and should cut down on conversion costs, since UTF-8 to unicode is a MUCH faster conversion than Shift-JIS to unicode. So storing like this cuts down one step, assuming you wish to handle all form data as unicode.
Slashdot Mirror
This is actually not entirely accurate. If you look a bit more closely at (especially) the Cocoa and (to a lesser extent) the Carbon APIs, both rely on the BSD layer for very important tasks, such as file system access (a recent technote mentioned the fact that since Carbon file-system access is mapped to BSD calls, certain things like exclusive-write access doesn't actually work).
In addition, the original video/audio feed is an analog stream. It is then digitized by your cable providor and sent to you. This may eventually change as more channels are natively digital, but this is quite a few years in the future.
Fantastic. This person re-iterates exactly the same URL link that was in the story (http://www.pdos.lcs.mit.edu/exo.html) and it gets moderated up to 4 as 'insightful'? Seriously, if you're going to moderate a story, the least you can do is click on the link so you know what you're moderating.
This is completely untrue. Objective C++ was included in MacOS 10.1. I'm using it as we speak. It allows you to mix Objective-C and C++ code freely in a single source code file. It works just as it should. It takes much longer to compile, though. Something about pre-processed headers, I think.
Do you have any documentation supporting this? This has all of the markings of an urban legend.
Wow. I'd hope for your sake that you're not the one negotiating with your internet providor. I've seen RETAIL bandwidth go for $2/gig in the US. Wholesale goes down lower than $1. At $2/gig, that's about $0.0019 per meg. That's a factor of 20-40x LESS than what your company is paying. I hope for your company's sake that you misplaced a decimal place somewhere.
I suspect in this case, the Trademark of "Coca Cola", as well as the logo, image, colors, etc, is owned by one company and licenced to the other.
But yes, your point is valid. Unless TLDs are split up along exactly the same lines as trademarks are (by the market segment the company is involved in) it is a losing proposition to pretend that one and only one company can own a single trademark.
Hmm... Maybe try the -ansi flag in gcc? In ANSI mode, it will error on any gcc-specific code.
The fact of the matter is, people DID blame Nobel, and he did feel guilty for creating dynamite. For this reason, he died alone and friendless, though mighty rich. Most see the Nobel Prize as being his way of buying himself a good name in the history books.
I do agree with your point, though.
I don't have to imagine. They already have her chest area hooked up to some sort of anti-gravity unit.
Just a few things to clarify and correct here:
The Carbon API is NOT a C++ API. It is purely a C API. Actually, I think it's still availible as a Pascal API, too, which was the language of choice for several years after the introduction of the Mac.
There are several C++ frameworks availible for Carbon. Powerplant, included (with source) with Codewarrior is one, MacApp, from Apple, is another.
The Finder is written using Powerplant, but does not take advantage of the new, more efficient event model availible in Carbon.
The differences between the two 'styles' of Carbon applications are that one style can work in OSX and OS8/9 with a single binary file, and the latter is in the native OSX executable format (Mach-O) which allows it to be linked with unix libraries and use lower level mach kernel services, and direct Quartz API calls.
You seem to be under the mistaken assumption that web sites are afforded the same protections under the law that broadcasters are. They're not.
$100k / $1M = -10- employees, not 100.
So, assuming your estimate of 1000 employees (which I think is high), that gives them enough cash to pay their employees for 5.4 months, not 4.5 years.
I hate to add to an obviously silly conversation, but you state that Be could not run BeOS on the new G3 Macs because Apple would not release the specs for the new hardware.
Good theory. And it is what Be said.
Do you know how long it took for the PPC Linux developers to get the Linux kernel running on the new G3 machine? About 2 weeks. How many people work on the PPC specific parts of the Linux kernel? About 2 or 3. I can only guess how many software engineers worked at Be at the time, but I imagine more than 2 or 3. So, how stupid do you think people are? Be didn't get BeOS running on the G3 because -THEY DIDN'T WANT TO- just as Elwood said in a parent post to this. The fact that they lied and whined that it was Apple's fault made me lose a great deal of respect for them.
I'd also like to point out that Apple is a HARDWARE VENDER. Do you think Apple makes money selling MacOS X for err, $89 or so? Of course not. It's a loss-leader to get people to buy their hardware which has a higher markup than most consumer PC hardware. People have been talking for years about how Apple should give up on hardware and moving to software. It won't happen. Apple losing control over their hardware platform would greatly reduce the added value that their products give over consumer PCs.
I saw a similar system (not exactly the same one) on TV used to put out one of the oil well fires in Kuwait. The system I saw was basically a large jet engine placed behind the stream of a large water hose. This was a fire that other methods had failed to bring under control for several days. They put the machine about 60 or 70 yards from the fire, turned it on, and within 5-7 seconds, the fire was out.
It got me thinking about why they don't use a system like this in conventional fires. I then realized that such a system would be increadibly destructive to a typical building, probably doing more damage than the fire would. (Imagine being sprayed with water travelling at several hundred mph).
I was also very hopeful when I first read this, but I still thought it was absolutely necessary for me to send in a thought-through email, as I urge EVERY Canadian here to do.
Go to http://strategis.ic.gc.ca/SSG/rp01099e.html (same link as parent message) and read particularly section 4.2.
Next, go to http://strategis.ic.gc.ca/SSG/rp01100e.html and read through it, and then send email to copyright-droitdauteur@ic.gc.ca
Please note that the email link on that page DOES NOT WORK (it links to the wrong email address), though the text of the link is correct.
If you are a Canadian computer professional, this is IMPORTANT. It doesn't seem like a helpless situation, either, as you will see after you read that paper (or the parent message for the highlights). Send an email and soon!
Just think, if we can keep Canada a friendly place for programmers to work, we can possibly end, or even reverse the brain-drain that's been going on for here for years and years.
Another good speculation I heard was that licencing issues relating to DVD software forced Apple to reduce the possibility of reverse-engineering the DVD playback software somehow, since MacOS X software is more hackable than earlier versions, since any program can be executed within gdb.
I'm not really sure why real-time kernel issues would factor into the performance, since they managed to port Quicktime over (though, granted, it's slower than it was in OS9).
Assuming the 800 costs $100 (Apple's cost), the 877 would cost around $150 each, but 2 800s would only cost $200, instead of $300 for 2 877s.
I think this is totally reasonable and definately smart for Apple. For people that can take advantage of the dual processors, the 77 mhz speed increase would be utterly overwhelmed by the speed bonus of the extra CPU.
What interested me was that the last the that Apple sold dual CPU machines (the 450), they positioned them, price-wise, BENEATH the 500mhz, single-CPU model.
Well, what you're implying here is that we have the ability to create a propulsion system where only a small fraction of the weight of the payload (most of it would be distributed to the power grid after it lands, presumably, only a small amount sending it back up again) would be fuel.
If we had ANY way of producing energy densities like that in a useful fuel, don't you think we'd be using them to send craft up into space right now?
Of course, I'm assuming that the mass of the payload would not change significantly in the loading/unloading process of the energy. That holds for almost anything I can think of.
While I'm not entirely happy with what Apple has done with their registration system, it's also entirely optional. If you're on broadband, simply unplug your machine from your network while you fill out your registration. It then tells you that you can send it later if you want to once you get online, but it doesn't enforce anything.
Also, may I point out:
--Apple Doesn't Require Serial Numbers For MacOS X!-- (It does for OSX Server, though)
I think that kinda beats out a small annoyance with the registration.
Just my $0.02CDN.
Well, thinking as an 'anarchist' might, I would simply swap a 240 VAC line for a high-powered laser if they switched to an optical connection. Voltage spikes are to be expected, but who's going to protect from an optical burst? :-)
This reminds me of the currently popular theory of how life arose, by simply taking constituant elements, heating them up and zapping them with lightning until they form amino acids and eventually proteins.
My theory, however, involves a freak accident involving a cage full of monkeys, a box of hand-held hole-punchers, a large stack of stiff paper and a punchcard reader.
Uhh... Are you a troll, or are you just really stupid? Have you actually TRIED gzipping a file more than once?
Original Tar file: 30720 bytes
Gzipped tar file: 6895 bytes
Gzipped gzipped tar file: 6923 bytes
Basically, you get ONE chance to properly discover all of the redundant data. After that, it's pretty much an uphill battle.
I've written several dynamic web sites using mySQL, JSP and servlets and this is what I did:
Stored the database internally in UTF-8 format and accessed it using unicode from the servlets.
Stored and served the HTML and JSP files in Shift-JIS format. As long as you tell the servlet that a JSP file is in shift-jis, any characters you write to the document as it's being processed will be converted automatically to shift-jis.
Because HTML forms are stupid and don't support (by default) character sets, you have to assume that the form will be sent back in the same character set the file was sent in. In Java, this meant telling the form handler to interpret the bytes as Shift-JIS which automatically converted them back into unicode, which would let me handle the form data in a uniform manner (1 character is 1 character, even its UTF-8 representation is more than one byte) and easily store it in the database in UTF-8.
As far as I knew, Python supported unicode strings, which would allow this type of handling. I recommend storing your database in some sort of native unicode format, which should make this fairly seamless and should cut down on conversion costs, since UTF-8 to unicode is a MUCH faster conversion than Shift-JIS to unicode. So storing like this cuts down one step, assuming you wish to handle all form data as unicode.