Most of your complaints seem aimed at C and not C++. Let's see:
* No standardized pragmas
You want standardized *compiler extensions*?
They standardized the extension mechanism. That sounds good for a start, but I don't see how you could go farther.
* Macros after-thought and not type safe C compatibility, basically deprecated now as they also affect everything, including members, variables, anything that gets #included, etc.
* No 24, and 32 bit (unicode) chars wchar exists, toghether with I/O stuff, though I'm not sure about the encoding type. You can even declare streams and strings for any character type you build.
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead * Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc... C compatibility. I believe they are inheriting the new types from C99 too. Also, short/int/long give you the sizes optimized for the specific processor, so you can use that if that's what you want. You can't really deprecate them because of that
* No distinction between typedefs and aliases What on earth is an alias? Are you talking about C's struct namespace? (one of the few things that C++ doesn't inherit)
* Inconsistent left-to-right declarations Inconsistent in what sense?
* Compilers still limited to ASCII source C++ has included trigraphs for over ten years now, which allow an editor to insert any unicode character and still store everything in ASCII for compatibility. Compilers don't even need to support unicode for things to just work. The editor just has to interpret the trigraphs and paint them on screen as the appropriate character.
I've never used them though.
* No binary constant prefix (even octal has one?!) I've never met anyone who actually worked in binary. Hex is close enough and less error-prone. Octal probably got included for a) C compatibility and b) People did use to work in octal (see file access permissions)
* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time Would you like a quite or signaling NaN?
I noticed it when downloading it for Linux. The reason I did that is I have a crappy connection at home and wanted a portable torrent client I can put on a USB stick and download from elsewhere (parents' house, friend's house, net-cafe, etc.)
Using utorrent under wine lets me be sure I can resume downloads from both Linux and Windows from the same USB stick without worrying about binary compatibility of the temp files.
Azureus is nicer but I'm not even sure how to make it portable, let alone ensure that an appropriate JVM is installed wherever I go.
FACT: there is absolutely no sensor or computer technology in the world that weighs a under and ounce and never ever will be! Yeah. Sputnik weighted 83.6Kg
You need to get an antenna and transmitter powerful enough to be trackedfrom earth an weighting 20 grams. Or put up some sort of light radar reflecting sail (only has to orbit 9 times on LEO and burn up, doesn't say it has to do anything useful).
I wonder if the tracking side is included in the budget or if you can borrow some really big antenna to try to detect the junk you put up.
People seem to be assuming you're some sort of internet vigilante or something. It occurs to me the such a unit has many options at its disposal, so, What is the task of your group?
- Support operations for army units overseas (peacetime/wartime) - Independent internet warfare during war time (Say WW3) - Independent internet defense during peacetime - Independent Offense/intelligence gathering during peacetime - Consulting for companies/agencies hardening their networks - Finding backdoors in preparation for an engagement - Helping companies close backdoors in their product - etc.
Also, is you unit mostly internet-oriented or do you handle other electronic warfare styles? (DoS/hacking by manipulating power lines, RF interference, etc)?
So essentially you're saying it is like Microsoft Windows. That should go down well here. More like a certain patchy server some people keep using to serve web pages.
A couple of your points
So what? Good MMOs are continuously updated for five to ten years. No reason to think you couldn't port it to a different platform and give it a graphical update in that time. But updating, say, from PS2 to PS3 is so far from trivial it's not even funny. Compare to going from XP to Vista, for example. For that expense you can port to Mac or Linux easily.
No businessman is going to make a decision of starting a project that is going to have to be ported to a new platform before even releasing, when you can stick to the PC and keep your investments low.
The only way I can think of convincing someone to do this is if you have advanced knowledge on the next console platform and start developing early, so as to be the flagship product of the console. Maybe the next XBox will focus on being an MMO box and allow the developers to get a head start by developing on a correctly configured PC.
Many, many people play MMOs (and other games for that matter) in pairs. I've played 6 different MMOs with my wife. Lots of people play with their spouses, siblings, or kids. And many, many people play console games in pairs, trios, or quartets. We tolerated split-screen for Goldeneye on the N64, where each player might get, what, 180x140 worth of screen space? And now we're on HD displays. And once again, we hit the hardware limitation problem.
In GoldenEye, both players were in the same map. In an MMO there is a chance that they'll be in completely different areas, and consoles don't usually have that much RAM, let alone having to split texture memory, etc. Likewise, barring cordless headphones, you'll be sharing sound too. And since you won't be reading as much, it's just a mess.
Then again, you could have two consoles on different TVs anyway.
Console MMOs really need to support split-screen play on a single machine, which adds to the development complexity. And developing for a single platform, instead of the "PC platform" of whatever the fsck the user decided to buy, should reduce development complexity. And it's easier to develop for x86+windows+OpenGL/DirectX than for multiple consoles or generations of consoles.
Seriously, consoles are nice and all, but the current hardware doesn't look like a match for MMOs. Maybe the next generation will include an MMO machine, with extra hard drive, wireless keyboard, specialized controller, headphones/microphone, voice recognition, enough memory for split screen, etc. But until then, don't bother.
You might have a point if one of the editors you mentioned wasn't emacs.
I could imagine an emacs-heavy shop wanting to develop custom scripts for supporting their workflow/standards/source control, only to be told they can't because one guy is using vi.
Also, someone smart enough to be proficient at vi would take a couple weeks to be just as proficient at emacs, so the lost productivity isn't that high anyway.
Okay... Well why not ditch the unnecessary robot, and just get a nice screen and a web cam? Seems like you could get that $8k cost down quite a bit and still end up with better looking video conferences. I think you're missing the point, or more like the article didn't explain things well. The original telepresence robot was IvanAnywhere. Basically Ivan moved away from his company, but was allowed to work remotely. E-mail and messaging wasn't enough, and it was frustrating to have just a camera in a single office/conference room and have to have people go there to talk to him.
So, he and a friend built a "robot", basically a mobile webcam/screen/speaker with wifi. If he needed to talk to a coworker, he'd grab his xbox controller and roll on down to their office, and talk "face-to-face". At lunch time, he'd wheel in to the conference room where everyone ate and chat with them while he ate at home.
It's not video-conferencing, it's telepresence. Being there while not being there. It actually sounds like a good idea when only a few people telecommute. Not worth $8000 though.
But that isn't what the article is about. The article is looking at a download link that is saturated from P2P transfers from other people. Since the DSLAM queue isn't in the users control, it is a bit harder to prevent the P2P traffic from saturating the link. Let me introduce you to my friend TCP Flow_control, which ensures that the sender only sends as fast as the receiver wants it.
Make sure your OS and application is sending out a small window to begin with (slow start) and that your client is set to only accept X kbps, and the sender will not send more than that rate./proc/core/net/ipv4 has a few settings along those lines IIRC. Yes, the sender will write fast enough to fill up your window at first, but if your window starts out small, this will not be a problem. The receiver can throttle down the connection by only sending ACKs for as much data as it wants to receive in the future, and it can control this by only calling read for as much data as it wants to process, thereby sliding the window and allowing the OS to ACK more data. Extra packet will be dropped by the OS when the window fills up without the APP reading it, getting the same "spacing out" result he wants. You'd have to look at how this interacts with Nagle's algorithm, but it should be OK.
I'm guessing either his software isn't coded with this in mind or his roommate didn't actually set up the down rate as he said he did.
You might even filter out ACKs at the router level (or clear the ACK bits if there is data) for all non-HTTP traffic, but I'm not sure of software to do this. You'd have to keep track of the how fast the connection is ACKing (which mean keeping track of all connections), etc. You'd also need to fix up window size announcement during the initial SYN. Dropping download packets will do the same thing.
Also, I think windows doesn't do slow start, which help for interactive sessions but will give you a burst as described every time a new server starts sending you data. I think you can set it with SO_RCVBUF in Posix, setReceiveBufferSize in java and probably the same option in windows, but I think those are hints anyway.
In fact, a steak through the heart is the likely cause of Cheney's becoming a cyborg in the first place! I can't tell if that's a normal, slashdot-level misspelling or if it was intentional to get the point across.
But half the companies out there aren't actually doing anything complicated.
I've been looking at open source ERP solutions (ERP5, Adempiere, etc.) and it makes me wonder whether you could set up a company that configures and manages servers and ERP systems. The actual boxes could be at your place or elsewhere.
Basically, you can offer companies a complete package for HR, order management, invoicing, payroll, etc. without them having to hire a single extra person. You'd have to have a clause in the contract to give them all their data and server configuration on demand, of course, maybe even send them weekly backups as part of your disaster recovery plan.
In the end you'd end up with a company of highly specialized people, giving your customers good response and high end features (mobile access? no problem), for less than it would cost them to have a team knowledgeable enough and able to do 24 hour support.
Of course companies would still need help desk and business-specific software, but that's less people (and is sometimes outsourced/contracted out anyway). You web presence would probably be custom made though.
And if you're an internet company, just forget it. (or then again, you hire a designer to provide custom CSS for the provider's web interface to the standard modules to the open source ERP system, which might be enough for half the sites out there too...hmmm....)
Wait for the FIN packet?...But apparently Linux uses RSTs anyway...
Oh, I know, wait for the second RST. When you get one, ignore and respond with an ACK or keepalive. IIRC, if the other side did close the connection, any extra packet is answered with another RST (Not sure about an empty ACK though).
If you receive a packet with a higher sequence number, the original RST was fake. If you get a second RST you acknowledge and close.
I'm not sure if you could do this at the firewall level or if you'd need to modify the TCP stack.
Then again this goes against the robustness principle of the Internet (be careful with what you send, forgiving with what you receive). It would be better to stop Comcast legally than to modify TCP and send exta packets without very careful study.
For some reason I get the feeling that they weren't trying to implant a new arm, but rather that it would've been considered cruel to cut off a monkey's healthy arm before the experiment.
But maybe I'm just being cynical about red tape in research.
Wouldn't it make more sense to create a Firefox extension that preloads this and/or redirects pages to use your local copy of these libraries?
It would be even easier with Google's hosting. Just hit them on startup, without referrer info, and then any site that links to Google's version is a little bit faster, and no privacy concerns exist.
You could even have the extension check if the file is changed and pop up a warning that google is being evil:)
I have it blacklisted on Adblock. Not so much because of the information but because it annoys me to see "waiting for google-analytics.com" on my status bar when I'm loading some other random web page. Slashdot is specially bad at this for some reason, so I blacklisted a bunch even if I'm allowing slashdot itself to display ads.
I think noscript still loads the file (I'm not sure), but adblock should prevent the request from going out. That should also prevent the referrer info.
But, as mentioned below, unlike urchin, the javascript libraries are supposed to not be reloaded, so the speed difference should be minimal.
To the hosts, yes I know you'd like to know more about me, but if it comes at a price of making my surfing experience slower, then you're not going to get it.
This is Web 2.0 hardware setup because users can add and modify servers as they see fit! Actually, I found this part interesting, from HP's offering:
When drives or the fans in the disk enclosures fail, the PolyServe software tells you which one has failed and where - and gives you the part number for ordering a replacement. Add a new blade or replace one that's failed and you don't need to install software manually. When the system detects the new blade, it configures it automatically. That involves imaging it with the Linux OS, the PolyServe storage software and any apps you have chosen to run on the ExDS; booting the new blade; and adding it to the cluster. This is all done automatically. Automatically scaling the system down when you don't need as much performance as you do during heavy server-load periods or marking data that doesn't need to be accessed as often, also keeps costs down. [emphasis mine]
I know, not what you meant, but a funny coincidence.
IBM is offering a more optimized rack, with shared and optimized power supplies, different arrangement for the fans, a heat exchanger in every rack for your building's air conditioner, (which Tom's interprets as water cooling) and a couple other things.
HP has a weird clustering software/hardware hybrid with large amounts/density of RAID 6 storage (for a flickr-style site, for example) together with a cluster of blades that can all access all the storage and can be added/removed at will. Interestingly they point at scaling down the system when load is low, to keep the costs down. I wonder if they put servers on stand-by automatically or something. They are also looking at not spinning all the disks all the time, but they're not there yet. I guess having some disks acting as a write cache could allow you to at least spin down the parity disks of the LRU sections or some such. You could even cache the read side if you're willing to put up with the spinup delay on a cache miss.
Supposedly this is Web 2.0 because you want a google-style cluster with lots of generic hardware where any one computer can go down and the whole thing keeps going. IBM wants to lower the maintenance costs, HP didn't show them the server side, but pushed their storage technology.
1) Global warming is occurring everywhere in the solar system due to increased solar activity.
2) This fact is completely unknown to most everybody who "believes" (as you put it) that global warming is a crisis. False dichotomy.
What about people who are not convinced that global warming is man-made and still think this constitutes a crisis?
Seriously, let's assume, as you do, that this is all caused by an unexplained increase in solar activity. What if this trend is going to continue? This would mean even more pronounced climate change, which affects the viability of our civilization, or at the very least will cause localized problems. Whether or not climate change is man made is completely irrelevant.
Actually, that's not true. If this is a natural cycle, then bringing climate back down to a livable condition will be even harder than just cleaning the pollution we've put in. And then we have to be able to put it back up when the solar cycle turns around.
In the end, for one reason or another, we have to terraform Earth.
It's just a planetary-scale engineering project, how hard can it be? We should get started.
[if I was in charge of a FOSS project] I would release when it was ready, not when some stupid release cycle rolled around, that is what everyone does not need is some schedule to pressure developers to release before a product is ready... When what is ready?
Most OSS projects have a whole lot of developers working on multiple features independently of each other. There is always at least one outstanding feature someone is working on. Even when a project gets labeled 1.0 people don't usually stop working and implementing new things
Release management is about two things: - When to release - What to release
Basically, you can work out around what date you want to release and figure out which big features will be ready for and merge those into a mainline and tell new things to hold off until release. Or the other possibility is to figure out which features you want in a version and then tell everyone else to hold off until those are stable.
If you have a distro schedule, you can still apply both of these. You can shoot for a couple months before and decide on which features will be ready. Or you can choose your features and then tell the distro whether it looks like it'll be ready or not. In this last case the distro still has a choice of whether to go with the last release or release a beta version (RedHat's GCC 2.96, Ubuntu's Firefox 3 Beta), and can make an informed decision by watching the projects and figuring out how close they are to release.
Shuttleworth is saying that if the distros synchronized, upstream developers would have better information about release cycles and could chose whether to target a particular release with their new features or not (essentially, when to branch for release and focus on stabilization). If it's not ready, then it's not ready and just shoot for 6 months later.
This guy Aaron makes a good point in that this shifts work upstream, but I don't agree that this is disruptive. Aaron's great idea? Have the distributors basically go into each and every project and make and manage the release branches themselves! Imagine someone else coming into your project and going "We're branching here because I said so". Gee, not very good with people is he?
If the distros synchronize, upstream can just ignore it if they feel like. There isn't really much of a downside. If you do chose to synchronize you can still have features released when they are ready, but deployments (releases/tarballs) happening on schedule. It's just a matter of which branches you merge.
On Ars' theory that big changes are prevented by a branch and merge, timed release approach, GCC has used a 3-stage (major change, improvement, stabilization) release cycle since GCC 3.1 in 2001. Rather large changes have been done since then until the 4.4 branch in development. Granted, Mark Mitchel has done a superb job at release management (i.e. cat herding) and recently had 3 more people join in in this job.
Even Linus does this fairly often (change too big, goes in next version so we can push this one out the door)
At best, distros could help with consulting and advising on this job, but the release planning and management must come from within each community. His point about shifting work is good, and release management for big, flaship projects could be provided by people from each company (as I'm sure redhat et al have people working on each project anyway), but big projects probably have something like it established anyway.
I'm still not seeing the downside to synchronized but ignorable schedules downstream.
Slashdot Mirror
Most of your complaints seem aimed at C and not C++. Let's see:
* No standardized pragmas
You want standardized *compiler extensions*?They standardized the extension mechanism. That sounds good for a start, but I don't see how you could go farther.
* Macros after-thought and not type safe C compatibility, basically deprecated now as they also affect everything, including members, variables, anything that gets #included, etc. * No 24, and 32 bit (unicode) chars wchar exists, toghether with I/O stuff, though I'm not sure about the encoding type. You can even declare streams and strings for any character type you build. * Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc... C compatibility. I believe they are inheriting the new types from C99 too.
Also, short/int/long give you the sizes optimized for the specific processor, so you can use that if that's what you want. You can't really deprecate them because of that * No distinction between typedefs and aliases What on earth is an alias? Are you talking about C's struct namespace? (one of the few things that C++ doesn't inherit) * Inconsistent left-to-right declarations Inconsistent in what sense? * Compilers still limited to ASCII source C++ has included trigraphs for over ten years now, which allow an editor to insert any unicode character and still store everything in ASCII for compatibility. Compilers don't even need to support unicode for things to just work. The editor just has to interpret the trigraphs and paint them on screen as the appropriate character.
I've never used them though.
* No binary constant prefix (even octal has one?!) I've never met anyone who actually worked in binary. Hex is close enough and less error-prone. Octal probably got included for a) C compatibility and b) People did use to work in octal (see file access permissions) * No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time Would you like a quite or signaling NaN?For double:
#include <limits>
const double inf = std::numeric_limits<double>::infinity ();
const double minf = -std::numeric_limits<double>::infinity ();
const double nan = -std::numeric_limits<double>::signaling_NaN();
See more here for example.
There are has_infinity() and related functions to check for a type's capabilities (say, in a template)
I noticed it when downloading it for Linux. The reason I did that is I have a crappy connection at home and wanted a portable torrent client I can put on a USB stick and download from elsewhere (parents' house, friend's house, net-cafe, etc.)
Using utorrent under wine lets me be sure I can resume downloads from both Linux and Windows from the same USB stick without worrying about binary compatibility of the temp files.
Azureus is nicer but I'm not even sure how to make it portable, let alone ensure that an appropriate JVM is installed wherever I go.
utorrent already does this. Their download page has a big button that lists wine first, IIRC.
You need to get an antenna and transmitter powerful enough to be trackedfrom earth an weighting 20 grams. Or put up some sort of light radar reflecting sail (only has to orbit 9 times on LEO and burn up, doesn't say it has to do anything useful).
I wonder if the tracking side is included in the budget or if you can borrow some really big antenna to try to detect the junk you put up.
People seem to be assuming you're some sort of internet vigilante or something. It occurs to me the such a unit has many options at its disposal, so, What is the task of your group?
- Support operations for army units overseas (peacetime/wartime)
- Independent internet warfare during war time (Say WW3)
- Independent internet defense during peacetime
- Independent Offense/intelligence gathering during peacetime
- Consulting for companies/agencies hardening their networks
- Finding backdoors in preparation for an engagement
- Helping companies close backdoors in their product
- etc.
Also, is you unit mostly internet-oriented or do you handle other electronic warfare styles? (DoS/hacking by manipulating power lines, RF interference, etc)?
No businessman is going to make a decision of starting a project that is going to have to be ported to a new platform before even releasing, when you can stick to the PC and keep your investments low.
The only way I can think of convincing someone to do this is if you have advanced knowledge on the next console platform and start developing early, so as to be the flagship product of the console. Maybe the next XBox will focus on being an MMO box and allow the developers to get a head start by developing on a correctly configured PC. Many, many people play MMOs (and other games for that matter) in pairs. I've played 6 different MMOs with my wife. Lots of people play with their spouses, siblings, or kids. And many, many people play console games in pairs, trios, or quartets. We tolerated split-screen for Goldeneye on the N64, where each player might get, what, 180x140 worth of screen space? And now we're on HD displays. And once again, we hit the hardware limitation problem.
In GoldenEye, both players were in the same map. In an MMO there is a chance that they'll be in completely different areas, and consoles don't usually have that much RAM, let alone having to split texture memory, etc. Likewise, barring cordless headphones, you'll be sharing sound too. And since you won't be reading as much, it's just a mess.
Then again, you could have two consoles on different TVs anyway. Console MMOs really need to support split-screen play on a single machine, which adds to the development complexity. And developing for a single platform, instead of the "PC platform" of whatever the fsck the user decided to buy, should reduce development complexity. And it's easier to develop for x86+windows+OpenGL/DirectX than for multiple consoles or generations of consoles.
Seriously, consoles are nice and all, but the current hardware doesn't look like a match for MMOs. Maybe the next generation will include an MMO machine, with extra hard drive, wireless keyboard, specialized controller, headphones/microphone, voice recognition, enough memory for split screen, etc. But until then, don't bother.
You might have a point if one of the editors you mentioned wasn't emacs.
I could imagine an emacs-heavy shop wanting to develop custom scripts for supporting their workflow/standards/source control, only to be told they can't because one guy is using vi.
Also, someone smart enough to be proficient at vi would take a couple weeks to be just as proficient at emacs, so the lost productivity isn't that high anyway.
So, he and a friend built a "robot", basically a mobile webcam/screen/speaker with wifi. If he needed to talk to a coworker, he'd grab his xbox controller and roll on down to their office, and talk "face-to-face". At lunch time, he'd wheel in to the conference room where everyone ate and chat with them while he ate at home.
It's not video-conferencing, it's telepresence. Being there while not being there. It actually sounds like a good idea when only a few people telecommute. Not worth $8000 though.
Never underestimate the bandwidth of a car carrying a bunch of cheap DVDs.
Make sure your OS and application is sending out a small window to begin with (slow start) and that your client is set to only accept X kbps, and the sender will not send more than that rate.
I'm guessing either his software isn't coded with this in mind or his roommate didn't actually set up the down rate as he said he did.
You might even filter out ACKs at the router level (or clear the ACK bits if there is data) for all non-HTTP traffic, but I'm not sure of software to do this. You'd have to keep track of the how fast the connection is ACKing (which mean keeping track of all connections), etc. You'd also need to fix up window size announcement during the initial SYN. Dropping download packets will do the same thing.
Also, I think windows doesn't do slow start, which help for interactive sessions but will give you a burst as described every time a new server starts sending you data. I think you can set it with SO_RCVBUF in Posix, setReceiveBufferSize in java and probably the same option in windows, but I think those are hints anyway.
Well done.
But half the companies out there aren't actually doing anything complicated.
...hmmm....)
I've been looking at open source ERP solutions (ERP5, Adempiere, etc.) and it makes me wonder whether you could set up a company that configures and manages servers and ERP systems. The actual boxes could be at your place or elsewhere.
Basically, you can offer companies a complete package for HR, order management, invoicing, payroll, etc. without them having to hire a single extra person. You'd have to have a clause in the contract to give them all their data and server configuration on demand, of course, maybe even send them weekly backups as part of your disaster recovery plan.
In the end you'd end up with a company of highly specialized people, giving your customers good response and high end features (mobile access? no problem), for less than it would cost them to have a team knowledgeable enough and able to do 24 hour support.
Of course companies would still need help desk and business-specific software, but that's less people (and is sometimes outsourced/contracted out anyway). You web presence would probably be custom made though.
And if you're an internet company, just forget it. (or then again, you hire a designer to provide custom CSS for the provider's web interface to the standard modules to the open source ERP system, which might be enough for half the sites out there too
Wait for the FIN packet? ...But apparently Linux uses RSTs anyway...
Oh, I know, wait for the second RST. When you get one, ignore and respond with an ACK or keepalive. IIRC, if the other side did close the connection, any extra packet is answered with another RST (Not sure about an empty ACK though).
If you receive a packet with a higher sequence number, the original RST was fake. If you get a second RST you acknowledge and close.
I'm not sure if you could do this at the firewall level or if you'd need to modify the TCP stack.
Then again this goes against the robustness principle of the Internet (be careful with what you send, forgiving with what you receive). It would be better to stop Comcast legally than to modify TCP and send exta packets without very careful study.
Come to think of it, a tail would be kind of useful every once in a while.
For some reason I get the feeling that they weren't trying to implant a new arm, but rather that it would've been considered cruel to cut off a monkey's healthy arm before the experiment.
But maybe I'm just being cynical about red tape in research.
Wouldn't it make more sense to create a Firefox extension that preloads this and/or redirects pages to use your local copy of these libraries?
:)
It would be even easier with Google's hosting. Just hit them on startup, without referrer info, and then any site that links to Google's version is a little bit faster, and no privacy concerns exist.
You could even have the extension check if the file is changed and pop up a warning that google is being evil
I have it blacklisted on Adblock. Not so much because of the information but because it annoys me to see "waiting for google-analytics.com" on my status bar when I'm loading some other random web page. Slashdot is specially bad at this for some reason, so I blacklisted a bunch even if I'm allowing slashdot itself to display ads.
I think noscript still loads the file (I'm not sure), but adblock should prevent the request from going out. That should also prevent the referrer info.
But, as mentioned below, unlike urchin, the javascript libraries are supposed to not be reloaded, so the speed difference should be minimal.
To the hosts, yes I know you'd like to know more about me, but if it comes at a price of making my surfing experience slower, then you're not going to get it.
When drives or the fans in the disk enclosures fail, the PolyServe software tells you which one has failed and where - and gives you the part number for ordering a replacement. Add a new blade or replace one that's failed and you don't need to install software manually. When the system detects the new blade, it configures it automatically. That involves imaging it with the Linux OS, the PolyServe storage software and any apps you have chosen to run on the ExDS; booting the new blade; and adding it to the cluster. This is all done automatically. Automatically scaling the system down when you don't need as much performance as you do during heavy server-load periods or marking data that doesn't need to be accessed as often, also keeps costs down. [emphasis mine]
I know, not what you meant, but a funny coincidence.
IBM is offering a more optimized rack, with shared and optimized power supplies, different arrangement for the fans, a heat exchanger in every rack for your building's air conditioner, (which Tom's interprets as water cooling) and a couple other things.
HP has a weird clustering software/hardware hybrid with large amounts/density of RAID 6 storage (for a flickr-style site, for example) together with a cluster of blades that can all access all the storage and can be added/removed at will. Interestingly they point at scaling down the system when load is low, to keep the costs down. I wonder if they put servers on stand-by automatically or something. They are also looking at not spinning all the disks all the time, but they're not there yet. I guess having some disks acting as a write cache could allow you to at least spin down the parity disks of the LRU sections or some such. You could even cache the read side if you're willing to put up with the spinup delay on a cache miss.
Supposedly this is Web 2.0 because you want a google-style cluster with lots of generic hardware where any one computer can go down and the whole thing keeps going. IBM wants to lower the maintenance costs, HP didn't show them the server side, but pushed their storage technology.
What? You don't have GreaseMonkey installed?
2) This fact is completely unknown to most everybody who "believes" (as you put it) that global warming is a crisis. False dichotomy.
What about people who are not convinced that global warming is man-made and still think this constitutes a crisis?
Seriously, let's assume, as you do, that this is all caused by an unexplained increase in solar activity. What if this trend is going to continue? This would mean even more pronounced climate change, which affects the viability of our civilization, or at the very least will cause localized problems. Whether or not climate change is man made is completely irrelevant.
Actually, that's not true. If this is a natural cycle, then bringing climate back down to a livable condition will be even harder than just cleaning the pollution we've put in. And then we have to be able to put it back up when the solar cycle turns around.
In the end, for one reason or another, we have to terraform Earth.
It's just a planetary-scale engineering project, how hard can it be? We should get started.
Most OSS projects have a whole lot of developers working on multiple features independently of each other. There is always at least one outstanding feature someone is working on. Even when a project gets labeled 1.0 people don't usually stop working and implementing new things
Release management is about two things:
- When to release
- What to release
Basically, you can work out around what date you want to release and figure out which big features will be ready for and merge those into a mainline and tell new things to hold off until release. Or the other possibility is to figure out which features you want in a version and then tell everyone else to hold off until those are stable.
If you have a distro schedule, you can still apply both of these. You can shoot for a couple months before and decide on which features will be ready. Or you can choose your features and then tell the distro whether it looks like it'll be ready or not. In this last case the distro still has a choice of whether to go with the last release or release a beta version (RedHat's GCC 2.96, Ubuntu's Firefox 3 Beta), and can make an informed decision by watching the projects and figuring out how close they are to release.
Did you even read the articles?
Shuttleworth is saying that if the distros synchronized, upstream developers would have better information about release cycles and could chose whether to target a particular release with their new features or not (essentially, when to branch for release and focus on stabilization). If it's not ready, then it's not ready and just shoot for 6 months later.
This guy Aaron makes a good point in that this shifts work upstream, but I don't agree that this is disruptive. Aaron's great idea? Have the distributors basically go into each and every project and make and manage the release branches themselves! Imagine someone else coming into your project and going "We're branching here because I said so". Gee, not very good with people is he?
If the distros synchronize, upstream can just ignore it if they feel like. There isn't really much of a downside. If you do chose to synchronize you can still have features released when they are ready, but deployments (releases/tarballs) happening on schedule. It's just a matter of which branches you merge.
On Ars' theory that big changes are prevented by a branch and merge, timed release approach, GCC has used a 3-stage (major change, improvement, stabilization) release cycle since GCC 3.1 in 2001. Rather large changes have been done since then until the 4.4 branch in development. Granted, Mark Mitchel has done a superb job at release management (i.e. cat herding) and recently had 3 more people join in in this job.
Even Linus does this fairly often (change too big, goes in next version so we can push this one out the door)
At best, distros could help with consulting and advising on this job, but the release planning and management must come from within each community. His point about shifting work is good, and release management for big, flaship projects could be provided by people from each company (as I'm sure redhat et al have people working on each project anyway), but big projects probably have something like it established anyway.
I'm still not seeing the downside to synchronized but ignorable schedules downstream.
Good point. The E's in the middle, for example, all have a dot in the top left of their icon. The sixes, on the other hand, don't