Easy, make it compile java bytecode and you probably have the biggest library around on the planet. Why a language nowadays should provide its own libraries is beyond me. That is so 90s...
You actually have a bigger library available if you can talk the C ABI (indeed, Java does this through JNI). But the general point - leverage someone else's set of libs instead of starting from scratch - is a very good one.
While I mostly agree with your post I would like to point out that I've met a few CS graduates, especially from "famous" schools, who have been in the habit of treating everyone else, including people who graduated from the same school as they did (sometimes even with with a Master's degree compared to their own Bachelor's) as if they knew nothing at all.
Here's a hint: those people are commonly known as "Assholes".
Having a bit of paper saying that you have indeed graduated does not make anyone a good person. It just makes them a person with a piece of paper. If the school is genuinely good, and the student was paying attention (hah!) then they'll know quite a lot about theory - that does help - but will need a lot more training in how to apply it. They should be able to pick up the practical parts rapidly; they damn well ought to have the conceptual framework to hang it off already. Whether they can actually do this... well, that's why they still start as noob developers, yes?
I say this as someone with a CS degree from a famous school.
The easiest way is if there's already support for loading libraries (dynamically would be nice!) and calling functions defined in C. If there is, then there's huge numbers of libraries to leverage (not all of which are in C, of course; that's just the most common basic ABI by far). Wrapping them up into libs that feel native (or reimplementing if someone's feeling energetic) can be done piecemeal.
Replying to myself. Meh...
Of more concern is the fact that Go is a GCed language with a mostly implicit thread model. That means it is probably impossible to write libraries/modules in it that can be used from other languages (handling the integration of the threading and GC engines is... non-trivial). That means that the language designers probably think that they're going to be the most important and highest-level language in use in the application. Not very humble!
Or, more likely, they just did the fun part of designing the language, and are leaving the hard part of creating libraries to somebody else.
The easiest way is if there's already support for loading libraries (dynamically would be nice!) and calling functions defined in C. If there is, then there's huge numbers of libraries to leverage (not all of which are in C, of course; that's just the most common basic ABI by far). Wrapping them up into libs that feel native (or reimplementing if someone's feeling energetic) can be done piecemeal.
Go has garbage collection and lacks pointer arithmetic. So... it won't replace C++, then?
For some uses, it will. Those will typically be the uses where writing it in C++ is not that good a solution anyway, and where trading off a lack of low-level access for a lower bug rate is worthwhile. As is usual with programming languages, the exact balance between restrictions and power comes out differently in different situations; removal of sharp tools from the toolbox can even sometimes be an enabler.
You're not much of a programmer if you only have one programming tool to work with. That's like being a joiner who only uses a hammer...
Why would an English-language institution lower its educational standards for lectures in order to cater to non-English-speaking students?
Because foreign students are (usually) more motivated to learn and they pay higher fees. The first tends to follow from the second; people tend to value expensive things more than cheap ones. (OSS is an apparent anomaly here, but that's off-topic.)
Besides, I was under the impression you had to take a language proficiency exam to attend school in a foreign language.
Yes, but that still doesn't mean that they find it easier to deal with spoken English than written. The reverse is more likely, TBH.
I was about to say the same thing. Unlike poker, the rules of the games are altered based on the current knowledge about the state of the game. This means that as soon as someone proclaims "We know the rules of Economics!", someone else is going to look at those rules and either game them to their benefit, or rewrite them to better suit their own purpose.
That just means that your fundamental modeling technique is probably best used in a multiagent system where the rules of each agent can be changed by sensing the success rate of other agents and their statements about their strategies. (I wonder how long it would take for lying and other forms of conniving back-stabbing to evolve in such a system...)
Yes, 3D in cinemas is impressive, quite stunning in fact, a far bigger, better improvement to film than HD and probably the most important change to film since colour in fact- I'd argue it beats surround sound for sure.
If only it worked for me when I tilt my head over on one side. Yes, it's a silly habit I picked up somewhere, but I really do have an issue with the 3D systems based on polarization because it's really hard for me to stop. Color works better, but then you're watching in (effective) monochrome.
The best system I've seen was a special monitor (this was back in a lab in 1994!) that directed a different image at each of about 16 directions at once. This meant that your eyes picked up different images naturally, and the net effect was an apparent 3D object that you could move your head from side to side to look round. Not that that is something which would work with cinemas though. IIRC, the main limitations at the time were display resolution, speed and brightness, all of which have improved since then. (OK, it was monochrome too, but there's no reason for that to have stayed as a limitation since they weren't using colors to encode spatial information.) I wonder what happened to that.
In fact, I'm not even convinced living room TV wants 3D terribly often, I think having to find your glasses to watch certain programs would become an annoyance after a while even if you don't mind it for the odd film.
With the proliferation of channels/bandwidth, it should be possible to transmit the same program in 2D at the same time.
We choose to do this as we are a "major" target - a medium sized public utility. I would guess many of the smaller utilities don't have the resources to do this.
OTOH, a smaller utility is more likely to be physically located close to the systems they need to maintain, making access that way less of a problem. It's the medium-sized utilities that have the real problem; they're geographically distributed and big enough to be "interesting" targets, but not so large that they've already taken proper steps to lock things down right (e.g., they might not have a full time digital security office).
Whether the utility is public or private makes little difference here, other than to the reasons for not running things as well as they should. The net effect is about the same.
In case you missed it, the newer versions of Pidgin support voice/video via XMPP/GTalk/etc.
Why would I use that if none of the people I want to call use it? Skype has a massive sitting-incumbent advantage. (No, I have no interest at all in developing VoIP systems; I work on other stuff.)
No. There would be problems with having to put that amount of upstream bandwidth in for all those website hosts. Maybe you think that that's practical and cost-effective, but that merely shows that you don't run a large, popular website and are unlikely to ever do so.
Without patents, only corporations would ever invent anything.
That's almost certainly untrue in general. Some people invent stuff because that's what sort of people they are, irrespective of the economic incentives (or not) for them to be like that. However, without patents you'd probably see the rise of guilds again as groups of inventors grouped together to share know-how and defend themselves against the rest of the world. Given the experience of the middle ages, patents are probably better for society overall. (Of course, one of the best things about patents is that they last for a fairly short time. If only economic copyright rights lasted only a similar amount, they'd be much less of a problem...)
Setuid is certainly a trade-off, but it seems a little absurd that you need full root permissions to access just the special resources "ping" needs to function. If anything, vulnerabilities like these are calls for a more fine-grained capability-based security system, that only grants the expected privileges needed for a given process to function.
You are aware that in order for ping to work at all, it needs raw sockets so that it can write ICMP packets? Those are restricted because they allow you to spoof all sorts of network traffic (e.g., the ethernet address to IP address mapping) Which Would Be Bad.
The only way to remove the setuid requirement from ping (apart from making your system thoroughly insecure) is to allow messages to be sent and received on raw sockets opened by non-root only if they're ICMP ECHO messages (I'm not aware of any other ICMP messages that it's useful for user code to send). Do you want to put such deep packet inspection in the kernel?
Or maybe they do provide the API, and the non-X11 branches of the code simply didn't use them because the guy writing the code didn't know how, and it hasn't been long enough for someone else to come around and fix it?
It's difficult to write good drawing engine abstractions that work efficiently over both X11 and Win32 because the correct point to apply caches is different at the two levels of abstraction. IIRC, it's easier to start with something closer to the Win32 view and go to X11 (in an efficient way, of course; without efficiency then you can do anything you want) than the other way round, but I might be way wrong in this since I haven't done proper deep GUI work for a while now (a few years).
OSX's basic drawing model has a lot in common with Win32, but the details are massively different. In many ways, OSX is more like display postscript...
The news is not that the East African rift will form a new ocean - that's been known for a few years - but that it can happen very quickly. A timescale of days for an event of that scale is really rather significant, since it means that if something like it were to happen anywhere near existing infrastructure, our ability to adapt to it would be extremely limited. Well, not until afterwards anyway.
Another geographical blunder in the article is saying that the rift will connect the Red Sea and the Gulf of Aden. That's because they're already connected.
You know what's already possible to do in the current web? Blinking text in comic sans font! Just grab your favorite gif maker and let it render some comic sans on it. Done!
Make it scroll too. After all, you can't underuse the <MARQUEE> tag...
Managed files Managed files are random-access files managed by a database or archive program. Random access is supported. The use of open modes O_SYNC, O_EXCL, or O_DIRECT during file creation indicates a managed file. Seeks while open for write are permitted, multiple opens access the same file, and O_SYNC and O_EXCL must work as documented. Unduplication via hashing probably isn't worth the trouble and is bad for database integrity.
O_EXCL is used sometimes for unit files too, such as when they want a guarantee that the file is created by them. This can be important in a security context.
A relatively small number of programs and libraries use "managed" files, and they're mostly databases of one kind or another.
There's more than there used to be due to the rise of the small-database-as-library, such as sqlite. Generally, this is a good thing (applications with data integrity without masses of configuration or reinvention of the wheel can hardly be anything but good!) but it does mean that more files are "managed" in your sense than used to be.
If these are the same idiots who "authorized" that god-awful movie
There is no I, Robot movie. There is no I, Robot movie. There is no I, Robot movie. (Maybe if I say it three times, close my eyes and put my fingers in my ears it will be true. It's got to be worth a try...)
Slashdot Mirror
They are providing free wireless for at least one hub - a Continental Airlines hub - Houston Bush.
Memphis is a Delta hub. (Not a bad place to change planes either, though the ceilings are a little low.)
Easy, make it compile java bytecode and you probably have the biggest library around on the planet. Why a language nowadays should provide its own libraries is beyond me. That is so 90s...
You actually have a bigger library available if you can talk the C ABI (indeed, Java does this through JNI). But the general point - leverage someone else's set of libs instead of starting from scratch - is a very good one.
While I mostly agree with your post I would like to point out that I've met a few CS graduates, especially from "famous" schools, who have been in the habit of treating everyone else, including people who graduated from the same school as they did (sometimes even with with a Master's degree compared to their own Bachelor's) as if they knew nothing at all.
Here's a hint: those people are commonly known as "Assholes".
Having a bit of paper saying that you have indeed graduated does not make anyone a good person. It just makes them a person with a piece of paper. If the school is genuinely good, and the student was paying attention (hah!) then they'll know quite a lot about theory - that does help - but will need a lot more training in how to apply it. They should be able to pick up the practical parts rapidly; they damn well ought to have the conceptual framework to hang it off already. Whether they can actually do this... well, that's why they still start as noob developers, yes?
I say this as someone with a CS degree from a famous school.
The easiest way is if there's already support for loading libraries (dynamically would be nice!) and calling functions defined in C. If there is, then there's huge numbers of libraries to leverage (not all of which are in C, of course; that's just the most common basic ABI by far). Wrapping them up into libs that feel native (or reimplementing if someone's feeling energetic) can be done piecemeal.
Replying to myself. Meh...
Of more concern is the fact that Go is a GCed language with a mostly implicit thread model. That means it is probably impossible to write libraries/modules in it that can be used from other languages (handling the integration of the threading and GC engines is... non-trivial). That means that the language designers probably think that they're going to be the most important and highest-level language in use in the application. Not very humble!
Or, more likely, they just did the fun part of designing the language, and are leaving the hard part of creating libraries to somebody else.
The easiest way is if there's already support for loading libraries (dynamically would be nice!) and calling functions defined in C. If there is, then there's huge numbers of libraries to leverage (not all of which are in C, of course; that's just the most common basic ABI by far). Wrapping them up into libs that feel native (or reimplementing if someone's feeling energetic) can be done piecemeal.
Go has garbage collection and lacks pointer arithmetic. So... it won't replace C++, then?
For some uses, it will. Those will typically be the uses where writing it in C++ is not that good a solution anyway, and where trading off a lack of low-level access for a lower bug rate is worthwhile. As is usual with programming languages, the exact balance between restrictions and power comes out differently in different situations; removal of sharp tools from the toolbox can even sometimes be an enabler.
You're not much of a programmer if you only have one programming tool to work with. That's like being a joiner who only uses a hammer...
Why would an English-language institution lower its educational standards for lectures in order to cater to non-English-speaking students?
Because foreign students are (usually) more motivated to learn and they pay higher fees. The first tends to follow from the second; people tend to value expensive things more than cheap ones. (OSS is an apparent anomaly here, but that's off-topic.)
Besides, I was under the impression you had to take a language proficiency exam to attend school in a foreign language.
Yes, but that still doesn't mean that they find it easier to deal with spoken English than written. The reverse is more likely, TBH.
I was about to say the same thing. Unlike poker, the rules of the games are altered based on the current knowledge about the state of the game. This means that as soon as someone proclaims "We know the rules of Economics!", someone else is going to look at those rules and either game them to their benefit, or rewrite them to better suit their own purpose.
That just means that your fundamental modeling technique is probably best used in a multiagent system where the rules of each agent can be changed by sensing the success rate of other agents and their statements about their strategies. (I wonder how long it would take for lying and other forms of conniving back-stabbing to evolve in such a system...)
Yes, 3D in cinemas is impressive, quite stunning in fact, a far bigger, better improvement to film than HD and probably the most important change to film since colour in fact- I'd argue it beats surround sound for sure.
If only it worked for me when I tilt my head over on one side. Yes, it's a silly habit I picked up somewhere, but I really do have an issue with the 3D systems based on polarization because it's really hard for me to stop. Color works better, but then you're watching in (effective) monochrome.
The best system I've seen was a special monitor (this was back in a lab in 1994!) that directed a different image at each of about 16 directions at once. This meant that your eyes picked up different images naturally, and the net effect was an apparent 3D object that you could move your head from side to side to look round. Not that that is something which would work with cinemas though. IIRC, the main limitations at the time were display resolution, speed and brightness, all of which have improved since then. (OK, it was monochrome too, but there's no reason for that to have stayed as a limitation since they weren't using colors to encode spatial information.) I wonder what happened to that.
In fact, I'm not even convinced living room TV wants 3D terribly often, I think having to find your glasses to watch certain programs would become an annoyance after a while even if you don't mind it for the odd film.
With the proliferation of channels/bandwidth, it should be possible to transmit the same program in 2D at the same time.
We choose to do this as we are a "major" target - a medium sized public utility. I would guess many of the smaller utilities don't have the resources to do this.
OTOH, a smaller utility is more likely to be physically located close to the systems they need to maintain, making access that way less of a problem. It's the medium-sized utilities that have the real problem; they're geographically distributed and big enough to be "interesting" targets, but not so large that they've already taken proper steps to lock things down right (e.g., they might not have a full time digital security office).
Whether the utility is public or private makes little difference here, other than to the reasons for not running things as well as they should. The net effect is about the same.
In case you missed it, the newer versions of Pidgin support voice/video via XMPP/GTalk/etc.
Why would I use that if none of the people I want to call use it? Skype has a massive sitting-incumbent advantage. (No, I have no interest at all in developing VoIP systems; I work on other stuff.)
Would anycast not be faster?
No. There would be problems with having to put that amount of upstream bandwidth in for all those website hosts. Maybe you think that that's practical and cost-effective, but that merely shows that you don't run a large, popular website and are unlikely to ever do so.
Without patents, only corporations would ever invent anything.
That's almost certainly untrue in general. Some people invent stuff because that's what sort of people they are, irrespective of the economic incentives (or not) for them to be like that. However, without patents you'd probably see the rise of guilds again as groups of inventors grouped together to share know-how and defend themselves against the rest of the world. Given the experience of the middle ages, patents are probably better for society overall. (Of course, one of the best things about patents is that they last for a fairly short time. If only economic copyright rights lasted only a similar amount, they'd be much less of a problem...)
Deal with those Too-Big-To-Fail
The internet is too big to fail...
You would have to line all of them up and use blanks in some of the guns.
Using some blanks? Sounds like a missed opportunity to me...
Setuid is certainly a trade-off, but it seems a little absurd that you need full root permissions to access just the special resources "ping" needs to function. If anything, vulnerabilities like these are calls for a more fine-grained capability-based security system, that only grants the expected privileges needed for a given process to function.
You are aware that in order for ping to work at all, it needs raw sockets so that it can write ICMP packets? Those are restricted because they allow you to spoof all sorts of network traffic (e.g., the ethernet address to IP address mapping) Which Would Be Bad.
The only way to remove the setuid requirement from ping (apart from making your system thoroughly insecure) is to allow messages to be sent and received on raw sockets opened by non-root only if they're ICMP ECHO messages (I'm not aware of any other ICMP messages that it's useful for user code to send). Do you want to put such deep packet inspection in the kernel?
BUY beachfront property NOW!
After a while* you'll be sitting on a goldmine!
There was a documentary on this business strategy a while ago.
Or maybe they do provide the API, and the non-X11 branches of the code simply didn't use them because the guy writing the code didn't know how, and it hasn't been long enough for someone else to come around and fix it?
It's difficult to write good drawing engine abstractions that work efficiently over both X11 and Win32 because the correct point to apply caches is different at the two levels of abstraction. IIRC, it's easier to start with something closer to the Win32 view and go to X11 (in an efficient way, of course; without efficiency then you can do anything you want) than the other way round, but I might be way wrong in this since I haven't done proper deep GUI work for a while now (a few years).
OSX's basic drawing model has a lot in common with Win32, but the details are massively different. In many ways, OSX is more like display postscript...
The news is not that the East African rift will form a new ocean - that's been known for a few years - but that it can happen very quickly. A timescale of days for an event of that scale is really rather significant, since it means that if something like it were to happen anywhere near existing infrastructure, our ability to adapt to it would be extremely limited. Well, not until afterwards anyway.
Another geographical blunder in the article is saying that the rift will connect the Red Sea and the Gulf of Aden. That's because they're already connected.
You know what's already possible to do in the current web? Blinking text in comic sans font! Just grab your favorite gif maker and let it render some comic sans on it. Done!
Make it scroll too. After all, you can't underuse the <MARQUEE> tag...
Actually writing a complex program in x86 assembly is more like "rebuild its engine using no other tools than a banana and a nail clipper".
Only if you're also starting from raw ores and have to do all the refining yourself to make the materials for the parts.
It doesn't help that said navy ships are also running Windows.
But it is Windows Naval Edition, more commonly called Portholes.
O_EXCL is used sometimes for unit files too, such as when they want a guarantee that the file is created by them. This can be important in a security context.
A relatively small number of programs and libraries use "managed" files, and they're mostly databases of one kind or another.
There's more than there used to be due to the rise of the small-database-as-library, such as sqlite. Generally, this is a good thing (applications with data integrity without masses of configuration or reinvention of the wheel can hardly be anything but good!) but it does mean that more files are "managed" in your sense than used to be.
Once we started down this slippery slope, there's no way to go back up.
There's the Second Amendment, and I say this as someone who would probably count as a liberal...
If these are the same idiots who "authorized" that god-awful movie
There is no I, Robot movie. There is no I, Robot movie. There is no I, Robot movie. (Maybe if I say it three times, close my eyes and put my fingers in my ears it will be true. It's got to be worth a try...)