um... I guess it ain't clear then... the parent post was saying that you need OS support for accelerated remote procedure calls and one-sided communications. However, 1 sided communications already is in standard use by folks using hundreds of processors through an already standardized library: MPI - Message Passing interface. Rather than the OS needing to define a new API, the folks creating high speed interconnects just create optimized libraries (in order to sell their hardware). Folks writing codes for hundreds of processors tend to want to treat them as array elements, so the chaotic calling of procedures just is not that useful. so the RPC support he is asking for is not really important.
In other words, the software stack for using large numbers of processors is already well-known. No need for any new OS features.
They are claiming a terabyte per second interconnect. I think it is safe to assume it will be something like an Infiniband, myrinet or similar (NEC's IXS, IBM's HPS) high performance application networking technology.
What you're asking for is pretty standard stuff in the high end, where hundreds of processors is quite common. Cache coherency is a killer, and so they have died out long ago in the high end. when you think about it, CC basically requires a crossbar switch style memory archictecture which expands with the square of the number of processors, and much higher speed logic to resolve conflicts. So eventually, it doesn't scale. Instead multiple applications with large numbers of processors tend to only have small groupings (say 8 or so, but can go upto 30 odd) using shared memory/cc access) and then MPI for anything bigger.
Clusters have been using MPI for years for this sort of thing. all the custom interconnects for supercomputing have customized implementations in their MPI libraries to take advantage of 1-sided communications. Most use a facility which can loosely be termed RDMA - remote direct memory access, another word sometimes used is OS-bypass. The idea is that for this sort of communications, you want to skip the TCP/IP stack and other OS buffering overhead, and just have straight memory to memory copies going on (under userland library control.)
folks generally don't do the direct invoking of things on other processors, but instead fire off jobs on blocks of processors, and have them communicate with 1-sided primitives. This is the sort of thing done on hundreds or thousands of processors today. It will just gradually percolate down to normal applications.
Don't forget Tcp Offload Engines, TOE for 10 GigE... those will probably be pointless as well. It would be cool to see how the interrupts are distributed to various cores at a rate of 1 G interrupts / second...
Software radio becomes programmable without specialised firmware... just raw transmission & recieve hardware connected to the mesh of cores. How will the FCC deal with that?
tv reception, cctv transmission & wlan on the same hardware...
* how easy is it for geeks meet women? Were trying to spread geekdom, right? * how much longer will it take these people to meet the opposite sex if they are laptop obsessed ? * now we just need some really involved mesh network games. * if they get educated, they will want to stay in school longer, and again delay reproductive activity.
I agree with your point, sometimes real-scissors and real glue are better than a word processor... but a it does not have to be all bad... mitigating factor would be that if people like coding, and they keep their practice up by implementing scripts in three hours, that could easily be saving you training hours, keeping their skills up for when they really need it, and improving coder morale... You might be just distributing training costs throughout your budget, and not having to shell out for it up-front in a five day course...
why would you want pixels when you have SVG? I can't think of any application where pixels are a good idea. pixels are a performance hack to render specific images more quickly.
This is the first uyear that OpenSSL is certifed by the government cryptographers as usable. This allows, for the first time, official government use of openssl as a solution in many, many government contract situations, where IPSEC or hardware would formerly have been required.
first: The developer is not some lone wolf performing creative work in a vacuum. A smart developer will take all the help they can from other sources. The whole point of open source is that testing is done by anybody with interest. If you think no testing is done by packagers, then you know squat about Debian. In the Debian model, there are 'maintainers' (the people who put software into Debian packages) as a completely separate group from 'upstream' (original developers.) The maintainers try to make the software work well within the distribution, make reasonable guesses about defaults and encourage consistency in how things are managed across packages. In addition, software in Debian repositories is built from source, and dependency management is done automatically. For example, a security issue is found in glibc, if the change causes breakage, it will propagate backwards. The maintainers will do first level diagnostics, and will be aware of general breakage and fixes applied to other packages which got similarly broken. They may try to apply a similar patch and feed the result back upstream. They can also collate multiple bug reports and act as first line support before problems hit the developer. This saves an incredible amount of work for the developer. Basically, the maintainer is doing distribution specific support for the package.
A dumb developer will insist on providing their own binaries "to ease the support burden" will be stuck personally supporting every version of every distribution, including learning all the quirks, dealing with the different release schedule, etc... with no help at all from the open source community. Providing your own packages is more work than having someone else help.
2nd: Yesterday's software?
What the heck is current? Have you tried Debian unstable? KUbuntu Dapper? Kubuntu is running Xorg, KDE 3.5.x, 2.6.15, etc... Folks who are willing to deal with some breakage can use pre-release versions and get the latest and greatest. Folks who prefer stability can get that, but need to accept older software. Folks who want just a few packages to be newer will run a stable release with some specific packages updated (via places like backports.org.) There is absolutely nothing stopping ISV's from creating their own repositories. That is even the right thing to do for companies that have sufficient commitment/resources to properly support a distribution's packages.
As for multi-gig games... Complete red-herring. If anything, Debian is proof of the opposite, A complete distribution is several DVD's and it works quite well, can be obtained via a number of means (such as torrents, jigdo, and straight iso's as well as DVD's if you want.) Providing a package for download is no different than putting a package in a repository, except that it is far less useful. If your point is that Games should be distributed on DVD's, that's fine, you can put repositories on DVD's too. That's how Debian works too. Repositories also automate the package selection for architecture, so you will not have to maintain two separate multi-gig blobs for AMD64 and i386.
3rdly: How do you download updates/patches for your multi-gig game? over the net? Well then there is no difference between that and a repository approach. It is even better to use repositories, because a good packager will split up the game into many, many distinct packages. When updates to the same package are supplied, the repository logic will mean that you will not have to download old versions of packages that have been replaced by future patches. With traditional blob patch approaches, you need to download all the patches and apply them in sequence.
Repositories are simply the best way to distribute software. It is only that people have a download reflex from the windows world that is nearly as bad as always being logged in as the admin. Download-itis is a sickness from windows, not a feature. Linux does some things better, and this is one of them.
If you were a new user to unix, what would you prefer:
A) open synaptic, search the thousands of packages, hope you find what you're after, install it.
B) download an app folder, drag it to your appliactions folder. go.
download from where? How did you find the place to download from? You did a google to find it first, on what term? the name of the software? the purpose? If the first step
is to do a search in synaptic (btw... Adept in ubuntu is nicer) that looks only for packages for your distro, version, and architecture. It is far simpler. And from now on, all your security updates are applied automatically, so the user does not have to worry about the latest and greatest.
A) is more:
Start up a software repository browser. (Click'n'run, Adept, Synaptic, whatever)
Do a reasonable search, to find the package, read among a few descriptions.
click on the install button. (which downloads and installs.)
B) is more like:
google search to find the web site of the software.
figure out where the download link is.
Try to figure out which package is correct for the computer (This step completely defeats most ordinary folks.)
Download it somewhere... (OK, it's on my desktop, now what do I do with this package thing?)
drag it into the applications folder (That assumes that you know what an applications folder is... again, inexperienced people will not know or worry.)
Folks hear about downloading, and expect to download, and application developers find packaging a pain, a barrier to distribution, but once people look at it critically,
it is really about what people are used to, not about what works better.
Downloading random packages off the net is a bad idea on any OS. Getting supported packages from a repository that tracks your OS is the right idea. Vendors of proprietary software should (and the good news is that many are) simply provide repositories for distros that provide for this kind of automatic updating.
People who say that repositories are not uptodate are not reasonable. Most people want software that has undergone some testing, want software to update itself automatically once it is installed, want the correct version for their system to be chosen automatically (i.e. asking people to be able to answer the question "on glibc 2.1 based distributions..." is too much.) The the software provider cannot find the time to perform proper packaging, and will not arrange for updates to be easy to do when there are security issues or improvements available, then you should not install the software unless you are prepared
to do that sort of support on your own. That is a choice that most people do not think about.
Making repositories easier to deal with is the thing to concentrate on. For example,
A missing piece right now would be to have an XML ''download selector'' which would contain a list of repositories for various distros, that frontends for apt/yum/whatever could just download and automatically select the appropriate repository for a given distribution. ISV's would just create the XML file (and the requisite repositories behind them.) And the whole manual download/install process would disappear. That would be a big end user improvement with only a small change existing tools.
Re:Spot On - FUD ... Japanese lack creativity...
on
Unusual Open Source
·
· Score: 2, Insightful
The hoary old They aren't creative mud slinging. This is exactly the same FUD levelled at the Japanese during the eighties... Theyre so regimented, they just copy, they cannot innovate. The fact is that making something good takes a lot of effort and experience, you get that experience from making stuff. The quickest way to make stuff is to copy it (with a large group of people you do not have to have endless discussions about what to do, because every one treats the original as a reference implementation.) After you have built it, people know what they are talking about and then incremental improvement can kick in. You can make it better than anyone elses.
Look at the GNU toolchain, then try the UNIX originals. The UNIX originals, frankly, suck in comparison. Were the UNIX folks more creative? Well they needed something, nothing existed, so they made something, there was no-one to copy. The gnu folks copied it because that way everone (aka the users) would know what it was. But they made it far better over time. Was anybody creative in the process? Sure. There was lots of creativity, but it was in dribs and drabs, in details, over a long period of time. What made the GNU stuff great was that it could capture all the improvements over time, because it was free software, where proprietary stuff would have severe NIH because of their licensing model (do not want to share revenues with every bozo that has an idea.)
The activity in the private sector that goes into creative innovation is miniscule compared to the amount that is either just plain obvious to someone in the domain, a minor improvement on something existing, or just outright copying/competing with somebody else. 99+% of creativity is obvious.
Look at Apple, the ipod was not creative in a technical sense. What distinguished it was the design and execution. How well it was done in comparison to other mp3 players and integration with itunes.
In every Western nation except the US, there are huge taxes on Gasoline, to the point where it costs three or four times what it does in the US. The US is going into huge deficit in order to fight a war (of hearts & minds, and at least partially about access to oil reserves.) The president has just said that Americans are addicted to Oil.
Isnt the first thing to do is to announce a regime of taxes on Gasoline, relatively little at first to prevent a shock to the economy, but announce that they will increase, year on year over time, in order to:
a) Discourage use of Oil. This incentivises people to find other sources of energy. b) Offsets the cost of the Iraq war, by having people who need the government service pay for it. pay back the debt. Thats a very conservative approach.
You seem young & bright. It seems like a good company. Financial services & consultants should be around for some time. Jobs like yours are very rare, I would not throw it away unless you are supremely confident in your ability to get another like it (I do not know what the environment is like in the Phillipines, maybe such jobs are common there because of outsourcing. In North America, they are rare.)
If you are not feeling challenged, then you probably have time to do experiments. Try some of those Excel/Access linkage projects and doing them in OOO & mysql as a demo. Or have the Excel files dropped onto an intranet, and then read-in using OOO to feed mysql and see if you can get interesting features from that.
Try finding ways to apply open source to what the clients need. It sounds like your work environment would be open to those sorts of experiments. See if you can have 20% time projects (like Google) or some such. I'd make the job interesting, since everything else about it is good.
If you are skilled, they will be flexible enough to accomodate you, and you will build relationships and skills at the same time.
The phone company does not have a monopoly on the local loop in Canada. It is required to offer, at a government set price, wholesale service to all comers. Miraculously, it still makes money hand over fist. The other result: 3 MB down/800K up ADSL with a static ip can be had for about 30 $US/month... 36 different DSL ISP's in Montreal ( a big city) according to... http://www.canadianisp.ca/ Oh, and the service is great too. Lastly, you can shop around the agreements to find one that allows servers, and does not block ports. They exist, because ISP's compete here.
How about making the site accessible for screen readers to assist the disabled. If you look into it, you will find that It has a lot in common with mobile users... Nobody can remember 15 menu items when they hear them, and then navigate back to them. Nobody can understand pages when they are described if they are too complicated.
You need to radically simplify presentation to make them comfortably usable by the bandwidth impaired, be it visual bandwidth in terms of vision, or using magnifiers, or using a PDA, or in terms of having the keep the structure in you head while listening to the page being described.
If the company is an Equal Opportunity Employer, and employees are expected to access the site, then they are pretty much compelled to make it accessible. You can get PDA support for free riding on that.
High Availability is actually a cost-cutter for people who have to provide a service.
We get a paged at 4am, told that a node has gone down, we thank them and go
back to sleep, fix it during the day. Hardware support can be Next Business Day, instead of 24x7, with no impact on the service given to clients. otoh, adding redundancy is not, really not, just something you slap on top of a single node application, unless the entire solution has been architected with that in mind.
What often happens is that people build normal applications, and then decide
to 'add reliability' by moving to HA. It works, but it is far more complicated than
doing it right, and such a solution is almost guaranteed not to scale. It is usually quite clunky, and testing configuration changes is difficult.
I'll just posit some terminology. HA usually is used to refer to failover methodologies (ie. piranha, linux-ha, (HP) MC/ServiceGuard, (SGI) FailSafe... what have you. Setting up HA is very complicated, and invariably includes some form of SPF in the form shared disk, or the arbitration system itself.
HA is actually not the best way to get maximum availability. What you want to do is try to make the application cloneable, be able to run multiple instances that at best do not need to talk to each other. Second best is if they talk to each other as if they were peers (no health check, just passing updates around like any other peer)... only after you have given up on that sort of architecture should you fall back on HA.
In my experience, you're right. But you have to take the long view. You don't just say... let's do an HA project, put it in, and walk away. to get more 9's you start with something that makes sense, and then look at every failure that happens, and fix the cause.
case in point: We started off with HA, figured out how to go to cloned configuration: two servers, two RAIDS, no SPoF, right? We had some LAN issues which caused traffic storms, there was a bug in the controller logic, so both RAIDS crashed simultaneously. We fixed it by using another brand of RAID for one of the units. Those servers have not crashed since...
If you do the accounting, the biggest cause of lack of availability with HA sites is number 18, 18 inches in front of the keyboard. That's not because people are less skilled than before, it is because we have eliminated all the hardware issues, the stuff you don't automate is all the stuff that is too complicated to automate, so only human error in making complicated changes remains. So every down time, there is usually an analyst looking sheepish, but it is usually not his/her fault. The process had some failing in it, and you have to fix the process. It's a lot like I hear airliner crash investigations are like. Find out what happenned, fix the process, so that it doesn't happen again.
You hone it over years, and every failure or even glitch is precious. Study it.
It's odd that all these people are answering without hearing a thing about your application. How big is the db? How often is it written? How often is it read?
For example, we run a site with data from a thousand odd different data sources, with each source getting updated every hour or so. We do it by parsing the data into static pages. We we receive a datum, we rebuild the pages that depend on it.
We have another site that runs off an Oracle db. the static page site runs about 90x faster, and is basically in memory (disk access is nil.) Now take into account that we can (and do) replicate the static page solution with zero load, we get to a solution that is literally 900x faster.
Now folks are thinking 'oh, the horror!' well... tough! There is no substitute for thinking about your data, and how it flows. A DB is not a given, but a (potentially wrong) answer to a question after you have done some analysis.
For my purposes, It doesn't matter how much work it is, it matters how much the wiring contractor charges for the work. I was signing the bills for re-termination and replacing of patch panels, and it was not cheap. I could lay new copper for the same cost of reterminating the fibre. We evaluated and we still went with fibre because we did not want long runs of copper, very similar to the design you describe (cisco 2950 XL's... two GBIC uplinks going to 6500 backbones)
The GBIC's going every other week: This is an problem that was widespread enough that Cisco's IOS has the UDLD (Unidirectional Link Detection) feature basically implemented specifically for broken GBIC's. We did not get strange looks, or odd questions from our vendor reps. There was a known problem with GBIC quality at the time (about four or five years ago, continued for two or three years.) and yes, we were using 100% Cisco products, no cheapies. It looks like it was fixed, because in the last year I don't remember replacing a single one.
We never do long runs of copper gigabit. The short runs in the machine room have not been any problem. Given choices,
Cat3-Cat7 vs. ST, SC, LC is a wash.
on
Fiber Optic vs Copper
·
· Score: 3, Informative
It's a marketing piece. As such nothing in there is actually false, just a little rose coloured.
The article says the same cable is used, but it glosses over the terminaors. I've gone through ST & SC, and now LC. Every couple of years they change the connector and then you stuck with frankefibres (patch cable with the new connector type on the patch, and the old on the machine.) It costs big bucks to replace your connectors. I hope they plan to stay with LC for a while, because replacing the connectors is nearly as expensive as replacing all the wiring.
We have an office building. The copper used to go down several floors to a central patch. We figured we'd modernise by having the copper terminate at switches on each floor, and run fibre down. Great except the fibre downlinks blow like popcorn. We were replacing cisco gbics every other week, and they're not cheap.
For long haul, I'm sure it makes a lot more sense, but in terms of building infrastructure, it would not have saved anybody much in the past 10 years if they had stayed with copper. And the end point electronics are still way more expensive.
Where fibre was a big win was with HIPPI. We had copper HIPPI and those cables were about an inch thick with 100 or so pin connectors. The fibre was just plain ST terminated multi-mode. Much easier to run.
If the phone companies start rolling it out in a big way, maybe the price for end point equipment will come down.
If the actual problem is that the day is 2ms. longer than it was in 1820, don't we have a pretty good basis for making a predictive leap second algorithm?
Say... we take the 2ms --> 500 days to lose a second, which is 43,200,000 seconds. Say it isn't exactly 2ms., say it is 1.99, so we can adjust the number of seconds to correspond to exactly the right time (call it L=42,984,000) to insert a leap second. Have a time reference which has a leap second every L seconds. How long will such a system be accurate?
If we want to keep using mostly every 18 months, then just adjust it to match reality... like every 18 months, except every 9 years, or some such, again, so that the algorithm is good for an long period into the future.
yeah... like a table that increases without bound is 'simple'... compare that to the leap year algorithm:
leap=0 if year % 4 == 0 :
if year % 100 == 0:
if year % 400 == 0:
leap=1
else
leap=0
else:
leap=1 else:
leap=0
The above function has been good for millenium or so. And is powerfully predictive. Your function, which was much longer, and has no ability to predict the future, isn't good for even two years in the future. Over 1800 years, the table will have to have 1200 odd entries in it.
I don't have anything against leap seconds. Just have an algorithm that specifies precisely when they will show up. Don't leave it as a random choice of a committee. If it is every 18 months, then insert two every three years, and that's it. If that turns out to be not quite right, make an sdjustment.. like every three years, except when divisible by 10, or whatever. but make it a consistent rule. Tables are pure chaos.
They're mining all this mass away from the center of gravity, and dumping it on the surface. so just we're slowing down just like a skater in a spin who puts out her arms.
(wild ass guess, but it's vaguely plausible, good enough for slashdot:-)
BBC article completely misses the point. The international time reference, since the 1950's, has been UTC, and used tuned according to atomic clocks, not the earth's rotation. There are time references used specifically for astronomy, such as sidereal time, solar time, etc... (http://en.wikipedia.org/wiki/Sidereal_time) There is absolutely no reason why astronomical time references have to match precisely to the time reference used by normal people.
The problem is that, today, there is no algorithm for knowing when to insert leap seconds ahead of time, which means you cannot calculate any time accurate to the second which is more than 18 months in the future, because you have no idea whether or not they will decide to insert a leap second. Nor is there any algorithm, other than a table of the known values to determine when to insert leap seconds. Add that they used to add them in June in some years, and December in others, and sometimes had two in the same year, and you get a feel for how chaotic it is.
Accumulate these differences over twenty years, and you have a serious problem. That is why the global positioning system uses it's own time reference, which has no leap seconds. When you're calculating position based on propagation delays, leap seconds are a mess. so GPS time is currently (http://tycho.usno.navy.mil/gpstt.html) fourteen or fifteen seconds different from UTC. (how many leap seconds since 1999? no way to calculate, you just have to know.) Seconds are the basis for all computer based time scales. These little nudges make very little sense. It would be far smarter to insert a leap minute, every... oh... 90 years. Or make the leap second insertion an algorithmic event, and not some random decision negotiated among a committee of astronomers.
And if you distrust monopolies so much, why advocate creating a government sponsored one?
I'm not suggesting creating any government sponsored monopolies. Regulation and government ownership (prices controlled by a board, such as in Bell Canada, and Hydro Quebec) cases are merely a means of trying to limit profiteering when you are stuck with them. A better option, when it is realistic, is to give the market a nudge, some sort of stimulus, carrot, stick, whatever. Public sector sponsoring development for products which they need (such as the Mass. initiative wrt to Open Document Formats) is a good way to try to break the network effect which makes Office a virtual monopoly.
Saying that price controls never work is too blanket an assertion. One should instead say that one would prefer to try other stimuli before pursuing price controls. Price controls make a lot of sense as a short term measure to cushion a shock, such as when Alberta de-regulated electricity, and the bills shot through the roof in a month or two (a bit like what happenned in California.)
Creating public corporations which compete with the private ones (such as Petro-Canada) when there is a perceived need to keep the industry honest, and divesting oneself of it, when that need is past (again, Petro-Canada) is perfectly reasonable. State intrustion does not have to mean state monopoly. It can be way to kick-start the market to greater competition.
History is rife with coercive monopolies, and they have always been bad news. The early history of Canada is steeped in Mercantalism, which doled out legal monopolies on portions of the economy. That was replaced in the 19th century by capitalism. Another form of state granted monopolies was alive and well in Franco's Spain. Not exactly a paragon of riches, that. So no, my main argument is that any monopoly that arises in a market is inherently bad and that the government should do something.
Wikipedia defines monopoly as: In economics, a monopoly (from the Greek monos, one + polein, to sell) is defined as a persistent market situation where there is only one provider of a kind of product or service. Monopolies are characterized by a lack of economic competition for the good or service that they provide and a lack of viable substitute goods. ( http://en.wikipedia.org/wiki/Monopoly ) The key to something being a monopoly is not pure market share, but a lack of competition, or viable substitute goods.
There is abolutely no need for a monopoly to be coercive for it to be bad. If you are stuck with one, the government should own it or regulate it heavily. If you can change the rules in such a way that there is competition, that is a far preferable solution (but for things like: water, power, and I would argue: bandwidth, they are un-avoidable natural monopolies.)
Slashdot Mirror
um... I guess it ain't clear then... the parent post was saying that you need OS support for accelerated remote procedure calls and one-sided communications. However, 1 sided communications already is in standard use by folks using hundreds of processors through an already
standardized library: MPI - Message Passing interface. Rather than the OS needing to define a new API, the folks creating high speed interconnects just create optimized libraries (in order to sell their hardware). Folks writing codes for hundreds of processors tend to want to treat them as array elements, so the chaotic calling of procedures just is not that useful. so the RPC support he is asking for is not really important.
In other words, the software stack for using large numbers of processors is already well-known. No need for any new OS features.
They are claiming a terabyte per second interconnect. I think it is safe to assume it will be something like an Infiniband, myrinet or similar (NEC's IXS, IBM's HPS) high performance application networking technology.
What you're asking for is pretty standard stuff in the high end, where hundreds of processors is quite common. Cache coherency is a killer, and so they have died out long ago in the high end. when you think about it, CC basically requires a crossbar switch style memory archictecture which expands with the square of the number of processors, and much higher speed logic to resolve conflicts. So eventually, it doesn't scale. Instead multiple applications with large numbers of processors tend to only have small groupings (say 8 or so, but can go upto 30 odd) using shared memory/cc access) and then MPI for anything bigger.
Clusters have been using MPI for years for this sort of
thing. all the custom interconnects for supercomputing
have customized implementations in their MPI libraries to
take advantage of 1-sided communications. Most use a facility which can loosely be termed RDMA - remote direct memory access, another word sometimes used is OS-bypass. The idea is that for this sort of communications, you want to skip the TCP/IP stack and other OS buffering overhead, and just have straight memory to memory copies going on (under userland library control.)
folks generally don't do the direct invoking of things on other processors, but instead fire off jobs on blocks of processors, and have them communicate with 1-sided primitives. This is the sort of thing done on hundreds or thousands of processors today. It will just gradually percolate down to normal applications.
Don't forget Tcp Offload Engines, TOE for 10 GigE...
those will probably be pointless as well. It would be cool
to see how the interrupts are distributed to various
cores at a rate of 1 G interrupts / second...
Software radio becomes programmable without specialised
firmware... just raw transmission & recieve hardware connected to the mesh of cores. How will the FCC deal with that?
tv reception, cctv transmission & wlan on the same hardware...
cool!
* how easy is it for geeks meet women? Were trying to spread geekdom, right?
* how much longer will it take these people to meet the opposite sex if they are laptop obsessed ?
* now we just need some really involved mesh network games.
* if they get educated, they will want to stay in school longer, and again delay reproductive activity.
ITs win, win, win...
I agree with your point, sometimes real-scissors and real glue are better than a word processor... but a it does not have to be all bad... mitigating factor would be that if people like coding, and they keep their practice up by implementing scripts in three hours, that could easily be saving you training hours, keeping their skills up for when they really need it, and improving coder morale... You might be just distributing training costs throughout your budget, and not having to shell out for it up-front in a five day course...
why would you want pixels when you have SVG?
I can't think of any application where pixels are a good idea.
pixels are a performance hack to render specific images more quickly.
Things will get better over time.
t m
This is the first uyear that OpenSSL is certifed by the government cryptographers as usable. This allows, for the first time, official government use of openssl as a solution
in many, many government contract situations, where IPSEC or hardware would formerly have been required.
http://csrc.nist.gov/cryptval/140-1/1401val2006.h
first:
The developer is not some lone wolf performing creative work in a vacuum. A smart developer will take all the help they can from other sources. The whole point of open source is that testing is done by anybody with interest. If you think no testing is done by packagers, then you know squat about Debian. In the Debian model, there are 'maintainers' (the people who put software into Debian packages) as a completely
separate group from 'upstream' (original developers.) The maintainers try to make the software work well within the distribution, make reasonable guesses about defaults and encourage consistency in how things are managed across packages. In addition, software in Debian repositories is built from source, and dependency management is done automatically. For example, a security issue is found in glibc, if the change causes breakage, it will propagate backwards. The maintainers will do first level diagnostics, and will be aware of general breakage and fixes applied to other packages which got similarly broken. They may try to apply a similar patch and feed the result back upstream. They can also collate multiple bug reports and act as first line support before problems hit the developer.
This saves an incredible amount of work for the developer. Basically, the maintainer is doing distribution specific support for the package.
A dumb developer will insist on providing their own binaries "to ease the support burden" will be stuck personally supporting every version of every distribution, including learning all the quirks, dealing with the different release schedule, etc... with no help at all from the open source community. Providing your own packages is more work than having someone else help.
2nd: Yesterday's software?
What the heck is current? Have you tried Debian unstable? KUbuntu Dapper? Kubuntu is running Xorg, KDE 3.5.x, 2.6.15, etc... Folks who are willing to deal with some breakage can use pre-release versions and get the latest and greatest. Folks who prefer stability can get that, but need to accept older software. Folks who want just a few packages to be newer will run a stable release with some specific packages updated (via places like backports.org.) There is absolutely nothing stopping ISV's from creating their own repositories. That is even the right thing to do for companies that have sufficient commitment/resources to properly support a distribution's packages.
As for multi-gig games... Complete red-herring. If anything, Debian is proof of the opposite, A complete distribution is several DVD's and it works quite well, can be obtained via a number of means (such as torrents, jigdo, and straight iso's as well as DVD's if you want.) Providing a package for download is no different than putting a package in a repository, except that it is far less useful. If your point is that Games should be distributed on DVD's, that's fine, you can put repositories on DVD's too. That's how Debian works too. Repositories also automate the package selection for architecture, so you will not have to maintain two separate multi-gig blobs for AMD64 and i386.
3rdly:
How do you download updates/patches for your multi-gig game? over the net? Well then there is no difference between that and a repository approach. It is even better to use
repositories, because a good packager will split up the game into many, many distinct packages. When updates to the same package are supplied, the repository logic will mean that you will not have to download old versions of packages that have been replaced by future patches. With traditional blob patch approaches, you need to download all the patches and apply them in sequence.
Repositories are simply the best way to distribute software. It is only that people have a download reflex from the windows world that is nearly as bad as always being logged in as the admin. Download-itis is a sickness from windows, not a feature. Linux does some things better, and this is one of them.
Folks hear about downloading, and expect to download, and application developers find packaging a pain, a barrier to distribution, but once people look at it critically, it is really about what people are used to, not about what works better. Downloading random packages off the net is a bad idea on any OS. Getting supported packages from a repository that tracks your OS is the right idea. Vendors of proprietary software should (and the good news is that many are) simply provide repositories for distros that provide for this kind of automatic updating.
People who say that repositories are not uptodate are not reasonable. Most people want software that has undergone some testing, want software to update itself automatically once it is installed, want the correct version for their system to be chosen automatically (i.e. asking people to be able to answer the question "on glibc 2.1 based distributions..." is too much.) The the software provider cannot find the time to perform proper packaging, and will not arrange for updates to be easy to do when there are security issues or improvements available, then you should not install the software unless you are prepared to do that sort of support on your own. That is a choice that most people do not think about.
Making repositories easier to deal with is the thing to concentrate on. For example, A missing piece right now would be to have an XML ''download selector'' which would contain a list of repositories for various distros, that frontends for apt/yum/whatever could just download and automatically select the appropriate repository for a given distribution. ISV's would just create the XML file (and the requisite repositories behind them.) And the whole manual download/install process would disappear. That would be a big end user improvement with only a small change existing tools.
Look at the GNU toolchain, then try the UNIX originals. The UNIX originals, frankly, suck in comparison. Were the UNIX folks more creative? Well they needed something, nothing existed, so they made something, there was no-one to copy. The gnu folks copied it because that way everone (aka the users) would know what it was. But they made it far better over time. Was anybody creative in the process? Sure. There was lots of creativity, but it was in dribs and drabs, in details, over a long period of time. What made the GNU stuff great was that it could capture all the improvements over time, because it was free software, where proprietary stuff would have severe NIH because of their licensing model (do not want to share revenues with every bozo that has an idea.)
The activity in the private sector that goes into creative innovation is miniscule compared to the amount that is either just plain obvious to someone in the domain, a minor improvement on something existing, or just outright copying/competing with somebody else. 99+% of creativity is obvious. Look at Apple, the ipod was not creative in a technical sense. What distinguished it was the design and execution. How well it was done in comparison to other mp3 players and integration with itunes.
In every Western nation except the US, there are huge taxes on Gasoline, to the point where it costs three or four times what it does in the US. The US is going into huge deficit in order to fight a war (of hearts & minds, and at least partially about access to oil reserves.) The president has just said that Americans are addicted to Oil.
Isnt the first thing to do is to announce a regime of taxes on Gasoline, relatively little at first to prevent a shock to the economy, but announce that they will increase, year on year over time, in order to:
a) Discourage use of Oil. This incentivises people to find other sources of energy.
b) Offsets the cost of the Iraq war, by having people who need the government service pay for it. pay back the debt. Thats a very conservative approach.
You seem young & bright. It seems like a good company. Financial services & consultants should be around for some time. Jobs like yours are very rare, I would not throw it away unless you are supremely confident in your ability to get another like it (I do not know what the environment is like in the Phillipines, maybe such jobs are common there because of outsourcing. In North America, they are rare.)
If you are not feeling challenged, then you probably have time to do experiments. Try some of those Excel/Access linkage projects and doing them in OOO & mysql as a demo. Or have the Excel files dropped onto an intranet, and then read-in using OOO to feed mysql and see if you can get interesting features from that.
Try finding ways to apply open source to what the clients need. It sounds like your work environment would be open to those sorts of experiments. See if you can have 20% time projects (like Google) or some such. I'd make the job interesting, since everything else about it is good.
If you are skilled, they will be flexible enough to accomodate you, and you will build relationships and skills at the same time.
The phone company does not have a monopoly on the local loop in Canada. It is required to offer, at a government set price, wholesale service to all comers. Miraculously, it still makes money hand over fist. The other result: 3 MB down/800K up ADSL with a static ip can be had for about 30 $US/month... 36 different DSL ISP's in Montreal ( a big city) according to... http://www.canadianisp.ca/ Oh, and the service is great too. Lastly, you can shop around the agreements to find one that allows servers, and does not block ports. They exist, because ISP's compete here.
How about making the site accessible for screen readers to assist the disabled. If you look into it, you will find that It has a lot in common with mobile users... Nobody can remember 15 menu items when they hear them, and then navigate back to them. Nobody can understand pages when they are described if they are too complicated.
You need to radically simplify presentation to make them comfortably usable by the bandwidth impaired, be it visual bandwidth in terms of vision, or using magnifiers, or using a PDA, or in terms of having the keep the structure in you head while listening to the page being
described.
If the company is an Equal Opportunity Employer, and employees are expected to access the site, then they are pretty much compelled to make it accessible. You can
get PDA support for free riding on that.
That's so cool! I'll just openly cheerlead... It is not the most popular language, so it is worth pointing out when it shows up somewhere unexpected.
What often happens is that people build normal applications, and then decide to 'add reliability' by moving to HA. It works, but it is far more complicated than doing it right, and such a solution is almost guaranteed not to scale. It is usually quite clunky, and testing configuration changes is difficult.
I'll just posit some terminology. HA usually is used to refer to failover methodologies (ie. piranha, linux-ha, (HP) MC/ServiceGuard, (SGI) FailSafe... what have you. Setting up HA is very complicated, and invariably includes some form of SPF in the form shared disk, or the arbitration system itself.
HA is actually not the best way to get maximum availability. What you want to do is try to make the application cloneable, be able to run multiple instances that at best do not need to talk to each other. Second best is if they talk to each other as if they were peers (no health check, just passing updates around like any other peer)... only after you have given up on that sort of architecture should you fall back on HA.
In my experience, you're right. But you have to take the long view. You don't just say... let's do an HA project, put it in, and walk away. to get more 9's you start with something that makes sense, and then look at every failure that happens, and fix the cause.
case in point:
We started off with HA, figured out how to go to cloned configuration: two servers, two RAIDS, no SPoF, right? We had some LAN issues which caused traffic storms, there was a bug in the controller logic, so both RAIDS crashed simultaneously. We fixed it by using another brand of RAID for one of the units. Those servers have not crashed since...
If you do the accounting, the biggest cause of lack of availability with HA sites is number 18, 18 inches in front of the keyboard. That's not because people are less skilled than before, it is because we have eliminated all the hardware issues, the stuff you don't automate is all the stuff that is too complicated to automate, so only human error in making complicated changes remains. So every down time, there is usually an analyst looking sheepish, but it is usually not his/her fault. The process had some failing in it, and you have to fix the process. It's a lot like I hear airliner crash investigations are like. Find out what happenned, fix the process, so that it doesn't happen again.
You hone it over years, and every failure or even glitch is precious. Study it.
It's odd that all these people are answering without hearing a thing about your application. How big is the db? How often is it written? How often is it read?
For example, we run a site with data from a thousand odd different data sources, with each source getting updated every hour or so. We do it by parsing the data into static pages. We we receive a datum, we rebuild the pages that depend on it.
We have another site that runs off an Oracle db. the static page site runs about 90x faster, and is basically in memory (disk access is nil.) Now take into account that we can (and do) replicate the static page solution with zero load, we get to a solution that is literally 900x faster.
Now folks are thinking 'oh, the horror!' well... tough! There is no substitute for thinking about your data, and how it flows. A DB is not a given, but a (potentially wrong) answer to a question after you have done some analysis.
For my purposes, It doesn't matter how much work it is, it matters how much the wiring contractor charges for the work. I was signing the bills for re-termination and replacing of patch panels, and it was not cheap. I could lay new copper for the same cost of reterminating the fibre. We evaluated and we still went with fibre because we did not want long runs of copper, very similar to the design you describe (cisco 2950 XL's... two GBIC uplinks going to 6500 backbones)
The GBIC's going every other week: This is an problem that was widespread enough that Cisco's IOS has the UDLD (Unidirectional Link Detection) feature basically implemented specifically for broken GBIC's. We did not get strange looks, or odd questions from our vendor reps. There was a known problem with GBIC quality at the time (about four or five years ago, continued for two or three years.) and yes, we were using 100% Cisco products, no cheapies. It looks like it was fixed, because in the last year I don't remember replacing a single one.
We never do long runs of copper gigabit. The short runs in the machine room have not been any problem. Given choices,
It's a marketing piece. As such nothing in there is actually false, just a little rose coloured.
The article says the same cable is used, but it glosses over the terminaors. I've gone through ST & SC, and now LC. Every couple of years they change the connector and then you stuck with frankefibres (patch cable with the new connector type on the patch, and the old on the machine.) It costs big bucks to replace your connectors. I hope they plan to stay with LC for a while, because replacing the connectors is nearly as expensive as replacing all the wiring.
We have an office building. The copper used to go down several floors
to a central patch. We figured we'd modernise by having the copper terminate at switches on each floor, and run fibre down. Great except the fibre downlinks blow like popcorn. We were replacing cisco gbics every other week, and they're not cheap.
For long haul, I'm sure it makes a lot more sense, but in terms of building infrastructure, it would not have saved anybody much in the
past 10 years if they had stayed with copper. And the end point electronics are still way more expensive.
Where fibre was a big win was with HIPPI. We had copper HIPPI and those
cables were about an inch thick with 100 or so pin connectors. The fibre was just plain ST terminated multi-mode. Much easier to run.
If the phone companies start rolling it out in a big way, maybe the
price for end point equipment will come down.
If the actual problem is that the day is 2ms. longer than it was in 1820, don't we have a pretty good basis for making a predictive leap second algorithm?
Say... we take the 2ms --> 500 days to lose a second, which
is 43,200,000 seconds. Say it isn't exactly 2ms., say it is 1.99, so we can adjust the number of seconds to correspond to exactly the right time (call it L=42,984,000) to insert a leap second. Have a time reference which has a leap second every L seconds. How long will such a system be accurate?
If we want to keep using mostly every 18 months, then just adjust it to match reality... like every 18 months, except every 9 years, or some such, again, so that the algorithm is good for an long period into the future.
yeah... like a table that increases without bound is 'simple'... compare that to the leap year algorithm:
leap=0
if year % 4 == 0 :
if year % 100 == 0:
if year % 400 == 0:
leap=1
else
leap=0
else:
leap=1
else:
leap=0
The above function has been good for millenium or so. And is powerfully predictive. Your function, which was much longer, and has no ability to predict the future, isn't good for even two years in the future. Over 1800 years, the table will have to have 1200 odd entries in it.
I don't have anything against leap seconds. Just have an algorithm that specifies precisely when they will show up. Don't leave it as a random choice of a committee. If it is every 18 months, then insert two every three years, and that's it. If that turns out to be not quite right, make an sdjustment.. like every three years, except when divisible by 10, or whatever. but make it a consistent rule.
Tables are pure chaos.
They're mining all this mass away from the center of gravity, and dumping it on the surface. so just we're slowing down just like a skater in a spin who puts out her arms.
:-)
(wild ass guess, but it's vaguely plausible, good enough for slashdot
BBC article completely misses the point. The international time reference, since the 1950's, has been UTC, and used tuned according
to atomic clocks, not the earth's rotation. There are time references used specifically for astronomy, such as sidereal time, solar time, etc... (http://en.wikipedia.org/wiki/Sidereal_time) There is absolutely no reason why astronomical time references have to match precisely to the time reference used by normal people.
The problem is that, today, there is no algorithm for knowing when to insert leap seconds ahead of time, which means you cannot calculate any time accurate to the second which is more than 18 months in the future, because you have no idea whether or not they will decide to insert a leap second. Nor is there any algorithm, other than a table of the known values to determine when to insert leap seconds. Add that they used to add them in June in some years, and December in others, and sometimes had two in the same year, and you get a feel for how chaotic it is.
Accumulate these differences over twenty years, and you have a serious problem. That is why the global positioning system uses it's own time reference, which has no leap seconds. When you're calculating position based on propagation delays, leap seconds are a mess. so GPS time is currently (http://tycho.usno.navy.mil/gpstt.html) fourteen or fifteen seconds different from UTC. (how many leap seconds since 1999? no way to calculate, you just have to know.) Seconds are the basis for all computer based time scales. These little nudges make very little sense. It would be far smarter to insert a leap minute, every... oh... 90 years. Or make the leap second insertion an algorithmic event, and not some random decision negotiated among a committee of astronomers.
And if you distrust monopolies so much, why advocate creating a government sponsored one?
I'm not suggesting creating any government sponsored monopolies. Regulation and government ownership (prices controlled by a board, such as in Bell Canada, and Hydro Quebec) cases are merely a means of trying to limit profiteering when you are stuck with them. A better option, when it is realistic, is to give the market a nudge, some sort of stimulus, carrot, stick, whatever. Public sector sponsoring development for products which they need (such as the Mass. initiative wrt to Open Document Formats) is a good way to try to break the network effect which makes Office a virtual monopoly.
Saying that price controls never work is too blanket an assertion. One should instead say that one would prefer to try other stimuli before pursuing price controls. Price controls make a lot of sense as a short term measure to cushion a shock, such as when Alberta de-regulated electricity, and the bills shot through the roof in a month or two (a bit like what happenned in California.)
Creating public corporations which compete with the private ones (such as Petro-Canada) when there is a perceived need to keep the industry honest, and divesting oneself of it, when that need is past (again, Petro-Canada) is perfectly reasonable. State intrustion does not have to mean state monopoly. It can be way to kick-start the market to greater competition.
History is rife with coercive monopolies, and they have always been bad news. The early history of Canada is steeped in Mercantalism, which doled out legal monopolies on portions of the economy. That was replaced in the 19th century by capitalism. Another form of state granted monopolies was alive and well in Franco's Spain. Not exactly a paragon of riches, that. So no, my main argument is that any monopoly that arises in a market is inherently bad and that the government should do something.
Wikipedia defines monopoly as:
In economics, a monopoly (from the Greek monos, one + polein, to sell) is defined as a persistent market situation where there is only one provider of a kind of product or service. Monopolies are characterized by a lack of economic competition for the good or service that they provide and a lack of viable substitute goods.
( http://en.wikipedia.org/wiki/Monopoly ) The key to something being a monopoly is not pure market share, but a lack of competition, or viable substitute goods.
There is abolutely no need for a monopoly to be coercive for it to be bad. If you are stuck with one, the government should own it or regulate it heavily. If you can change the rules in such a way that there is competition, that is a far preferable solution (but for things like: water, power, and I would argue: bandwidth, they are un-avoidable natural monopolies.)