no ISO body has deprecated functions like close(2), open(2), read(2), and write(2)
That's correct, because ISO C++ never included those functions in the first place. POSIX != ISO C. (Not that MSVC is on any kind of reasonable schedule for keeping up with ISO standards, but that's a whole different issue...)
Basically MS is deprecating their own terrible implementation of some POSIX compatibility. This is actually required for ISO C compliance: the compiler is not supposed to define a bunch of extraneous functions in the global namespace, because they might conflict with your names. Once those functions are removed entirely (and I believe you can #define them away right now) you can implement your own compatibility functions for software you're porting to Windows.
Now, this is all entirely separate from the SDL warnings GP is complaining about, which show up when you use standard ISO C functions like strcpy, sprintf, and apparently now memcpy. Which, honestly, I wish weren't quite so irritatingly implemented, although I'm torn because using those functions really is terrible.
It's not really that worth getting up in arms about, though, because JESUS CHRIST there's a compiler flag to disable the warnings, just put it in your makefile and quit bitching already!
Since we're being smartasses, actually you do, because the 6502 only has an 8-bit adder implemented in hardware. If you want to add 32-bit numbers you need to write a sequence of add-with-carry instructions.
Also I don't know why you'd want to use a broom at all to clean up damp pet food, I always use paper towels. Icky.
Okay, and factor in that they'll probably use more efficient cells than the random (foldable) ones I picked off the internet -- maybe, then. That's a damn expensive lot of track, if we're talking 3 or 4 million square meters of cells, but maybe.
Running the figures through Google math, starting with a 60"x42" panel generating 55W at peak, I calculate a 116 mile x 2 meter strip of solar panels would generate ~12MW. That's an order of magnitude short... I don't know what kind of duty cycle the 110MW is required at, but if that's continuous to run the train line, it's only going to be able to operate for an hour a day.
It's enough to make one suspicious about feasibility, anyway.
What's your point? Processors can pipeline across branches just fine, and the main effect of cache is to give a performance boost to smaller code -- code that separates and reuses functions rather than inlining them willy-nilly.
Inlining can still be a win sometimes, but compilers will do that for you automatically anyway...
Actually the idea makes sense. When they say VM, they mean like Java VM, or.NET runtime VM. The quote you pasted has the goods: "this VM has no means to convert integer to pointer". So you can't make a pointer into your neighbour process' data unless that neighbour process gives you such a pointer, because the only way to get pointers in the first place is from malloc().
This is the basis of security in sandboxed Java applications, it's not controversial or new. IIRC MS Research is working on a similar operating system that uses the.NET runtime -- ah yes, Singularity OS.
The state save on shutdown, far from being the best thing about this OS, as far as I'm concerned is the worst thing. Even if the software written for this thing is bug-free and never corrupts its own state, hardware is not 100% reliable -- memory gets corrupted, disks get corrupted, drivers end up wedged in unexpected states due to flaky hardware.
Imagine if a BSOD-equivalent occurs due to something that got corrupted 30 seconds ago, and that state got persisted to disk. From now on, every time you turn the machine on, you have less than 30 seconds before that exact same BSOD happens. Congratulations, your computer is now useless until you reinstall your OS! Brilliant.
The obvious workaround is, of course, to save program state out regularly as files in a constrained, standard format, which is independent of your program's implementation. Other reasons you might want to do this include upgrading software and interoperation between different applications.
But of course, as soon as you admit that, you admit that the new paradigm is not actually going to be a programming revolution at all, from an application perspective. You have to be able to save your state to a file and restore it: the only difference is that now that code will get executed less. As a programmer, though, it makes no difference to me whether the code is executed once or a million times, it's exactly the same effort to write it.
The filesystem is an ugly anachronism in a lot of ways, but it's also really, really technically practical.
That said, I wouldn't be surprised either if we were using VM-based operating systems in 10 years or so. There are some really interesting things you can do with JIT compilation when the OS and application code are not divided by a giant wall. But I do think they'll have filesystems of some sort.
I would imagine they work pretty much the same way bans, embargoes, and tariffs work for all goods: exports and imports are declared by the sender and inspected at the border. The government bodies that deal with imports and exports have been doing it for a really long time.
That's not to say smuggling doesn't happen, but I think by now it's a pretty well-understood problem.
When the ban was put in place the people who put it in place surely knew roughly how many printers were likely to be smuggled in from the US anyway, how many would come from sources in other countries, etc. I can believe there wasn't a good reason for passing the law, but assuming they were completely ignorant of the possibility of smuggling is going a little far...
Wow, that's really fascinating, because the Sweeney article you mention has him going on and on about generally programmable vector processors which make heavy use of that SIMD thing you so hate.
Oh wait, I didn't mean fascinating, I meant boring and you're an idiot. Engineers don't implement SIMD instructions because vector processors are easy to program, they implement them because they are cheap enough that they're worth having even if you hardly use them, never mind problem domains like graphics where you're expecting to use them all the time.
(And yes, I did read your article too, just to be charitable. It's amusing that you think the Cell is "a perfect example of how not to design a multicore processor", because the first step of writing software that performs well on the Cell is to break it down into a signal processing chain. What's hilarious, though, is that you think this will make software easier to write. Clearly you haven't tried to write any real software using your proposed system yet, much less worked with a team on it.)
For most people shipping costs are in fact free. The replacement process is not without hassle -- I had to request a box 3 times before actually getting one, though you could legitimately blame their shipping company for that -- but the whole thing never cost me a dime, and I had my '360 back within two weeks of sending it off. I live in Canada; I don't know how it is overseas, of course.
(For reference, the process is this: you call their toll-free line, spend about 10-20 minutes going through an automated system and then waiting on hold, then talk to a person for a few more minutes. A couple days later there's a box on your doorstep, which you pack up and send off at no cost. A week or two later the console comes back fixed. They'll do this for any '360 purchased ever, if you have RROD -- I worked on a "launch window" title and had one I got on launch day direct from MS.)
What on earth makes you think a pacifist is the kind of personality that would go toe-to-toe with a crazy asshole breaking shop windows? The psychology of protesters and protests is not nearly that simple.
I'm actually a bit surprised you haven't heard of protests where violent protests get ejected or shunned by otherwise peaceful protesters, because yes it happens... every once in a while the thugs trying to start a riot even turn out to be undercover police, too, although it's not like there's a shortage of moronic "burn the government" crazies either.
But any issue you haven't spent time actually researching looks pretty trivial, so there you go.
Of course it does: according to that article, if you change the NIC, only 4 items on the list have to change to require reactivation, including the NIC. So, if you do a CPU upgrade that requires a new motherboard, that's at a minimum going to change the NIC (built onto motherboard), IDE adapter (built onto motherboard), CPU type, and CPU serial number -- yep that's 4 things right there. In fact, chances are it'll also hit the video card and SCSI adapter.
So really it's not at all surprising. If you were going to be generous, you could suggest that XP's activation policy was designed before it became impossible to buy a motherboard without the kitchen sink.
Its like flu shots. I travel, talk, do meetings, etc. I get sick very rarely, yet I see so many immediately taking "flu vaccines" out of fear that the flu will kill them. I've never had a relative who either died of the flu or had complications. Neither have I known anyone in my personal life who had these complications, and I have associates who have lived in first, second as well as third world scenarios.
What a terrible argument! "I don't know anyone it happened to so it doesn't matter". I've never been in an air crash, and I don't know anyone who has, but I'm damned happy that aircraft design, certification and maintenance is done very carefully even if it is a little inconvenient, because I'd really rather keep it that way.
Anyway, influenza probably won't kill you as long as you're young and healthy, but it's well-documented that it does kill people, especially older people and the immune-compromised. The flu shot isn't just to keep yourself from getting sick, it's a public health concern: you're preventing yourself from being a carrier and getting other people sick. The argument that you don't usually get sick is missing the point.
This is all completely ignoring the facts that flu pandemics have happened in the past (3 in the last hundred years, according to Wikipedia), that the only thing different today is that we have vaccines (do I have to point out that they're useless if nobody uses them?), and that in these days of global travel, if a particularly nasty strain were to break out it could be immensely devastating internationally. It's not like flu shots are exactly onerous... I spent probably 20 minutes lining up and getting mine this past fall. If they hadn't done a free clinic at work it would've been maybe a couple hours out of my life, tops, and $15.
I mean, don't live your life in fear... but don't use bad logic to justify skipping things that hardly cost you anything and provide a measurable benefit to yourself and to society.
I think there are optics in there to change the focal distance, too.
I mean, maybe you're so blind you can actually focus on something an inch and a half away from your eye comfortably, but I'm only a little myopic, and trying to focus closer than about 3" hurts... hmmm... yeah, I'd say that hurts like a bitch.
Thanks a lot, now I have a headache from doing my fact check.
Now, of course Nyquist's theorem is correct. It's a theorem. Mathematically speaking it's unassailable.
But in practice, there's a caveat for real-world applications: by the same math, any frequencies over half your sampling rate that get into your source get converted into frequencies less than half your sampling rate. New, audible sounds that didn't exist in the source! And they sound absolutely awful.
So you need a filter that removes those sounds as aggressively as possible from your input with as little effect as possible on the audio you want to keep.
Here's the crux of the issue: 44kHz sampling only gives you a 10% frequency margin to go from "zero perceptible effect on the audio" to "completely blocks all audio". As it turns out this filter is pretty much impossible to build. Designers either compromise by allowing some rare aliasing noise (most audio equipment isn't designed to respond well above 20kHz anyway), or by starting the cut a little early (most people can't hear much above 16kHz anyway). As a general aside, the narrower and more accurate your filter is, the more delay it adds to your audio, so there's a latency issue, too.
It's much easier to build a filter that gradually cuts out audio starting somewhere above 20kHz and finishing completely (100dB or 150dB cut) by 40kHz for use with 96kHz sampling. And this is why 96kHz sampling is better: nothing to do with being able to hear over 20kHz, but merely engineering tradeoffs.
That said, you're right, most people can't tell the difference, or if they can it doesn't matter to them. And yes, you could probably record at 96kHz and use a (very computationally expensive) digital filter to downsample to 44kHz and produce something indistinguishable in mastering, but then I'm not actually a signal processing expert..
Sure. The point is that Jade isn't putting herself forth as a sex symbol, Ubisoft isn't either, it's the media and fan response that's doing that. Predictably, maybe, but I can't hold Ubisoft so responsible for something they didn't actually do themselves.
When people complain about how much media attention she's getting, they're mostly responding to the phenomenon and the interpretation of what Ubisoft PR did and not what they actually did, which was put someone who should be well-qualified to talk about the game and represent the developers and who had good experience doing publicity in the position of doing publicity. Shock! Horror!
Part of the response seems to be that people didn't at first believe that she could possibly be qualified for her job, and instead assumed she was put in that position just so she could do PR as a pretty face... which is the absolutely shaming part of this whole thing.
Well, not only was she the Producer but she was basically the lead PR rep because of the way Ubisoft used her.
I'm really having a hard time getting what the big deal about this is. I work at a fairly large studio (100-200 people on staff), and my impression has always been that the producer has two main reponsibilities:
1. Manage the leads: resolve conflicts, deal with staffing, and keep everyone on the same game vision;
2. Deal with the outside world: champion the game and sell it to the studio heads or publisher, and arrange the PR.
If the producer can do a decent interview, then sure as shit they'll be out there pimping the game. The producer on my last title was a bearded guy with a bit of a gut. Did he do PR footwork anyway? Yes he did, when it wasn't more important to get the lead designer in an interview.
The people making Jade Raymond into a sex symbol are the people gawking over some PR photos where she's basically standing with her team in jeans and a plain cotton top, probably the same clothes she wears to the office every day. WTF.
They have no geek passion. They are irrelevant to the discipline. And they are exactly what Corporate America wants them to be.
Whatever, I have geek passion, I just don't have all-consuming geek passion. My job is a perfect outlet for the geek passion -- I get to be a geek all day. Then in my off-time I can hang out with friends, listen to music, dance, cook, whatever other hobbies I'm currently pursuing.
I'm pretty sure that if I worked in sales or management I'd have to work on electronics or write code when I got home. I sure did when I was going to school.
Google says: 25 horsepower = 18.6424968 kilowatts; 52 / 18.6 = 2.8 hours, which is closer to the right ballpark. I don't know where your 25 horsepower to maintain 100km/h came from, but you're going to require less energy per kilometer at lower speeds, and they may be making different assumptions about the construction of the car that mean it'll be more efficient...
And really, we're close enough to the right amount of energy here that if maybe you need to put two of these in instead of one, that's not a big deal. I'm pretty excited!
Slashdot Mirror
That's correct, because ISO C++ never included those functions in the first place. POSIX != ISO C. (Not that MSVC is on any kind of reasonable schedule for keeping up with ISO standards, but that's a whole different issue...)
Basically MS is deprecating their own terrible implementation of some POSIX compatibility. This is actually required for ISO C compliance: the compiler is not supposed to define a bunch of extraneous functions in the global namespace, because they might conflict with your names. Once those functions are removed entirely (and I believe you can #define them away right now) you can implement your own compatibility functions for software you're porting to Windows.
Now, this is all entirely separate from the SDL warnings GP is complaining about, which show up when you use standard ISO C functions like strcpy, sprintf, and apparently now memcpy. Which, honestly, I wish weren't quite so irritatingly implemented, although I'm torn because using those functions really is terrible.
It's not really that worth getting up in arms about, though, because JESUS CHRIST there's a compiler flag to disable the warnings, just put it in your makefile and quit bitching already!
Since we're being smartasses, actually you do, because the 6502 only has an 8-bit adder implemented in hardware. If you want to add 32-bit numbers you need to write a sequence of add-with-carry instructions.
Also I don't know why you'd want to use a broom at all to clean up damp pet food, I always use paper towels. Icky.
Okay, and factor in that they'll probably use more efficient cells than the random (foldable) ones I picked off the internet -- maybe, then. That's a damn expensive lot of track, if we're talking 3 or 4 million square meters of cells, but maybe.
Running the figures through Google math, starting with a 60"x42" panel generating 55W at peak, I calculate a 116 mile x 2 meter strip of solar panels would generate ~12MW. That's an order of magnitude short... I don't know what kind of duty cycle the 110MW is required at, but if that's continuous to run the train line, it's only going to be able to operate for an hour a day.
It's enough to make one suspicious about feasibility, anyway.
What's your point? Processors can pipeline across branches just fine, and the main effect of cache is to give a performance boost to smaller code -- code that separates and reuses functions rather than inlining them willy-nilly.
Inlining can still be a win sometimes, but compilers will do that for you automatically anyway...
Actually the idea makes sense. When they say VM, they mean like Java VM, or .NET runtime VM. The quote you pasted has the goods: "this VM has no means to convert integer to pointer". So you can't make a pointer into your neighbour process' data unless that neighbour process gives you such a pointer, because the only way to get pointers in the first place is from malloc().
This is the basis of security in sandboxed Java applications, it's not controversial or new. IIRC MS Research is working on a similar operating system that uses the .NET runtime -- ah yes, Singularity OS.
The state save on shutdown, far from being the best thing about this OS, as far as I'm concerned is the worst thing. Even if the software written for this thing is bug-free and never corrupts its own state, hardware is not 100% reliable -- memory gets corrupted, disks get corrupted, drivers end up wedged in unexpected states due to flaky hardware.
Imagine if a BSOD-equivalent occurs due to something that got corrupted 30 seconds ago, and that state got persisted to disk. From now on, every time you turn the machine on, you have less than 30 seconds before that exact same BSOD happens. Congratulations, your computer is now useless until you reinstall your OS! Brilliant.
The obvious workaround is, of course, to save program state out regularly as files in a constrained, standard format, which is independent of your program's implementation. Other reasons you might want to do this include upgrading software and interoperation between different applications.
But of course, as soon as you admit that, you admit that the new paradigm is not actually going to be a programming revolution at all, from an application perspective. You have to be able to save your state to a file and restore it: the only difference is that now that code will get executed less. As a programmer, though, it makes no difference to me whether the code is executed once or a million times, it's exactly the same effort to write it.
The filesystem is an ugly anachronism in a lot of ways, but it's also really, really technically practical.
That said, I wouldn't be surprised either if we were using VM-based operating systems in 10 years or so. There are some really interesting things you can do with JIT compilation when the OS and application code are not divided by a giant wall. But I do think they'll have filesystems of some sort.
I would imagine they work pretty much the same way bans, embargoes, and tariffs work for all goods: exports and imports are declared by the sender and inspected at the border. The government bodies that deal with imports and exports have been doing it for a really long time.
That's not to say smuggling doesn't happen, but I think by now it's a pretty well-understood problem.
When the ban was put in place the people who put it in place surely knew roughly how many printers were likely to be smuggled in from the US anyway, how many would come from sources in other countries, etc. I can believe there wasn't a good reason for passing the law, but assuming they were completely ignorant of the possibility of smuggling is going a little far...
Wow, that's really fascinating, because the Sweeney article you mention has him going on and on about generally programmable vector processors which make heavy use of that SIMD thing you so hate.
Oh wait, I didn't mean fascinating, I meant boring and you're an idiot. Engineers don't implement SIMD instructions because vector processors are easy to program, they implement them because they are cheap enough that they're worth having even if you hardly use them, never mind problem domains like graphics where you're expecting to use them all the time.
(And yes, I did read your article too, just to be charitable. It's amusing that you think the Cell is "a perfect example of how not to design a multicore processor", because the first step of writing software that performs well on the Cell is to break it down into a signal processing chain. What's hilarious, though, is that you think this will make software easier to write. Clearly you haven't tried to write any real software using your proposed system yet, much less worked with a team on it.)
For most people shipping costs are in fact free. The replacement process is not without hassle -- I had to request a box 3 times before actually getting one, though you could legitimately blame their shipping company for that -- but the whole thing never cost me a dime, and I had my '360 back within two weeks of sending it off. I live in Canada; I don't know how it is overseas, of course.
(For reference, the process is this: you call their toll-free line, spend about 10-20 minutes going through an automated system and then waiting on hold, then talk to a person for a few more minutes. A couple days later there's a box on your doorstep, which you pack up and send off at no cost. A week or two later the console comes back fixed. They'll do this for any '360 purchased ever, if you have RROD -- I worked on a "launch window" title and had one I got on launch day direct from MS.)
What on earth makes you think a pacifist is the kind of personality that would go toe-to-toe with a crazy asshole breaking shop windows? The psychology of protesters and protests is not nearly that simple.
I'm actually a bit surprised you haven't heard of protests where violent protests get ejected or shunned by otherwise peaceful protesters, because yes it happens... every once in a while the thugs trying to start a riot even turn out to be undercover police, too, although it's not like there's a shortage of moronic "burn the government" crazies either.
But any issue you haven't spent time actually researching looks pretty trivial, so there you go.
Of course it does: according to that article, if you change the NIC, only 4 items on the list have to change to require reactivation, including the NIC. So, if you do a CPU upgrade that requires a new motherboard, that's at a minimum going to change the NIC (built onto motherboard), IDE adapter (built onto motherboard), CPU type, and CPU serial number -- yep that's 4 things right there. In fact, chances are it'll also hit the video card and SCSI adapter.
So really it's not at all surprising. If you were going to be generous, you could suggest that XP's activation policy was designed before it became impossible to buy a motherboard without the kitchen sink.
Anyway, influenza probably won't kill you as long as you're young and healthy, but it's well-documented that it does kill people, especially older people and the immune-compromised. The flu shot isn't just to keep yourself from getting sick, it's a public health concern: you're preventing yourself from being a carrier and getting other people sick. The argument that you don't usually get sick is missing the point.
This is all completely ignoring the facts that flu pandemics have happened in the past (3 in the last hundred years, according to Wikipedia), that the only thing different today is that we have vaccines (do I have to point out that they're useless if nobody uses them?), and that in these days of global travel, if a particularly nasty strain were to break out it could be immensely devastating internationally. It's not like flu shots are exactly onerous... I spent probably 20 minutes lining up and getting mine this past fall. If they hadn't done a free clinic at work it would've been maybe a couple hours out of my life, tops, and $15.
I mean, don't live your life in fear... but don't use bad logic to justify skipping things that hardly cost you anything and provide a measurable benefit to yourself and to society.
Jacks are sockets. It's always been a great mystery of tech jargon to me that female connectors are referred to as jacks.
I think there are optics in there to change the focal distance, too.
I mean, maybe you're so blind you can actually focus on something an inch and a half away from your eye comfortably, but I'm only a little myopic, and trying to focus closer than about 3" hurts... hmmm... yeah, I'd say that hurts like a bitch.
Thanks a lot, now I have a headache from doing my fact check.
Uh, whoops, a better assumption would be that 0.44" is the diagonal measurement:
(0.44 inches) / sqrt((800^2) + (600^2)) = 11.17600 microns
Google calculator says:
(0.44 inches) / 800 = 13.97 microns
Still an order of magnitude or so away, but wow, that's a lot closer than I thought..
It's not a bad way to learn how imperfect your own memory is, and gain a little damn humility.
Now, of course Nyquist's theorem is correct. It's a theorem. Mathematically speaking it's unassailable.
But in practice, there's a caveat for real-world applications: by the same math, any frequencies over half your sampling rate that get into your source get converted into frequencies less than half your sampling rate. New, audible sounds that didn't exist in the source! And they sound absolutely awful.
So you need a filter that removes those sounds as aggressively as possible from your input with as little effect as possible on the audio you want to keep.
Here's the crux of the issue: 44kHz sampling only gives you a 10% frequency margin to go from "zero perceptible effect on the audio" to "completely blocks all audio". As it turns out this filter is pretty much impossible to build. Designers either compromise by allowing some rare aliasing noise (most audio equipment isn't designed to respond well above 20kHz anyway), or by starting the cut a little early (most people can't hear much above 16kHz anyway). As a general aside, the narrower and more accurate your filter is, the more delay it adds to your audio, so there's a latency issue, too.
It's much easier to build a filter that gradually cuts out audio starting somewhere above 20kHz and finishing completely (100dB or 150dB cut) by 40kHz for use with 96kHz sampling. And this is why 96kHz sampling is better: nothing to do with being able to hear over 20kHz, but merely engineering tradeoffs.
That said, you're right, most people can't tell the difference, or if they can it doesn't matter to them. And yes, you could probably record at 96kHz and use a (very computationally expensive) digital filter to downsample to 44kHz and produce something indistinguishable in mastering, but then I'm not actually a signal processing expert..
Sure. The point is that Jade isn't putting herself forth as a sex symbol, Ubisoft isn't either, it's the media and fan response that's doing that. Predictably, maybe, but I can't hold Ubisoft so responsible for something they didn't actually do themselves.
When people complain about how much media attention she's getting, they're mostly responding to the phenomenon and the interpretation of what Ubisoft PR did and not what they actually did, which was put someone who should be well-qualified to talk about the game and represent the developers and who had good experience doing publicity in the position of doing publicity. Shock! Horror!
Part of the response seems to be that people didn't at first believe that she could possibly be qualified for her job, and instead assumed she was put in that position just so she could do PR as a pretty face... which is the absolutely shaming part of this whole thing.
1. Manage the leads: resolve conflicts, deal with staffing, and keep everyone on the same game vision;
2. Deal with the outside world: champion the game and sell it to the studio heads or publisher, and arrange the PR.
If the producer can do a decent interview, then sure as shit they'll be out there pimping the game. The producer on my last title was a bearded guy with a bit of a gut. Did he do PR footwork anyway? Yes he did, when it wasn't more important to get the lead designer in an interview.
The people making Jade Raymond into a sex symbol are the people gawking over some PR photos where she's basically standing with her team in jeans and a plain cotton top, probably the same clothes she wears to the office every day. WTF.
So you don't think good judgement about how to mitigate risk is a driving skill? Interesting.
Okay, so it was a stupid pun. We're agreed then!
Whatever, I have geek passion, I just don't have all-consuming geek passion. My job is a perfect outlet for the geek passion -- I get to be a geek all day. Then in my off-time I can hang out with friends, listen to music, dance, cook, whatever other hobbies I'm currently pursuing.
I'm pretty sure that if I worked in sales or management I'd have to work on electronics or write code when I got home. I sure did when I was going to school.
It's a feature! How else are the poor astronauts supposed to guarantee they'll be home in time for a rockin' new year's eve?
Google says: 25 horsepower = 18.6424968 kilowatts; 52 / 18.6 = 2.8 hours, which is closer to the right ballpark. I don't know where your 25 horsepower to maintain 100km/h came from, but you're going to require less energy per kilometer at lower speeds, and they may be making different assumptions about the construction of the car that mean it'll be more efficient...
And really, we're close enough to the right amount of energy here that if maybe you need to put two of these in instead of one, that's not a big deal. I'm pretty excited!