They switched their store systems over... http://www.novell.com/success/burlington.html I bet this is their desktops in back offices and such. perhaps this will be 'inspiring' to them to finish the job.
You package has dependencies. It requires the version of glibc and a dozen other libraries you built it with. Do you talk to the developers of glibc and the dozen other libraries? if they want to upgrade their libraries what do you do?
If you want to be independent then you take a copy of glibc that you used to build your app. you install it it in its own appdir so your app can use it. You do that for each of your dozen dependencies. Then you are independent.
Benefits:
-- your app is independent.
costs:
-- no shared library usage because every application is going to want its own copy of twelve libraries.
-- massive disk space cost because every application is going to...
-- large number of copies of the same f2#@%#! library on the system is usually pointless.
-- this is how windows works, and their term for this situation is DLL hell because you have no clue
which version of a particular DLL is being used by any application.
Now lets say there is a security problem in glibc. You can either:
a) tell your users to screw off, they paid for software and you gave it to them, two year old glibc and all. Security is somebody elses problem.
b) be out of business, in which case refer ex-customers to a)
c) have a server available for your customers to download patches from. Those patches will include patches to all the libraries which you depend on. So you have to validate and produce packages for all of the twelve libraries which you depend on. You maintain complete packaging, including all dependencies, for each and every distribution you support. You are able to, on request, verify which packages need updating, and perform coherent updates (perhaps multiple dependencies have to be updated together with your application in order for it all to work together.)
Congratulations! you are now running a repository with dependency management. One step further and you can have your own distro.
Of course, you could avoid that by simply listing in the requirements for the software all the library versions they must have (which is fine, unless they feel the need to upgrade their OS at some point, and your app breaks.) but then that forces the user to use repository tools to satisfy dependencies... hmm... why not automate that by having the application know what its dependencies are!... Again, you have just invented apt-get/aptitude/yum.
The alternative is to cultivate package maintainers for various distros, let them maintain the packages for the distributions, let them understand the weirdnesses of each one and help you with packaging issues. Use them as filters for bug reports, so that if the problem is distro specific, they look at it first.
All applications use the same glibc (and any other common dependency) saving huge amounts of disk and memory space. Now when a new glibc patch comes out, the build cluster will automatically re-compile your package if needed and any other dependencies against it, and your clients will automatically received (a single copy of) the patched glibc, and the patched application, with zero effort on your part. If you are getting weird problem reports from a particular distro, talk to the packager and try to work it out together. build a relationship, dont swear about his existence. You are wrong, life is not simple, and swearing at people that reveal that it is more complicated than you would like to believe is stupid.
The second reason you are lacking in vision is that you pretend that there is some bright line between the OS and applications. Get a f$#% clue! to the guy writing BIND or djbdns, DNS is an application. in the 1980s, berkeley networking was an optional application stack on
First. It mixes in meta-data with data. Metadata should be somewhere else, because, well obviously, if I have 1500 configuration files for slight variations of the same thing, then Im going to have 1499 pointless copies of metadata. keep the validation information and real data separate, dammit.
Second. XML parsing is 10 to 100 times slower than parsing a text file. You have clearly never written a text file parser and an XML parser. Using a reasonable language like python, text file parsing is trivial. XML parsing is simply not to be attempted without a library, its that painful. When you are going to read 10,000 config files, it matters. If you adopt this scheme widely, you will end up reading that large number of files. XML structure doesnt add anything useful. It is not easier to read than a standard text file. It is not more concise. It will be expensive.
Third. when upgrading your software, all the metadata can change, If you want to upgrade and see what the differences are... good luck! Comments, upper bounds, etc... will all change. Keeping meta data separate from configuration, allows you to diff the meta data separately from the configuration info.
Fourth. I18n and i10n. If you wanted to do your approach thoroughly, you would have 150 translations of all the textual meta data in the same file. That file is going to be one big sucker. Put it in a separate file? fine. do it consistently instead of treating one language as special.
Fifth. If you have All this XML meta data in a separate file and the text file stays in exactly the same format, you still get all the goodness, and you havent lost anything. The only requirement for this is to have a couple of text file parsers. There are not that many flavours of such text file formats, so some XML tag could identify the grammar approach. The text file, concise, to the point, easily parsed by experienced humans, remains untouched.
Sixth: you completely miss the point of text files. They are a user interface. To me, a text file with a simple, easy to understand grammar, together with an application that identifies format errors is the easiest, most flexible, most effective way to manage application configuration. I regularly strip out comments from configuration files because to me, 99% of the comments are noise. If I wanted documentation on the format, I would look in a man page. Configuration information is a list of settings. The point of text files is that they are human editable, human auditable, diffable, revision controllable. When you make the file format too noisy for a human to parse, you lose the entire benefit of a text file in the first place. It might as well be binary, because no human can safely edit the file anymore (Its too !@%#$@! complicated to edit the file and get all the tags and metadata correct.) The user of a text configuration file is a human. Making him type, or understand five times or ten times as much text to configure the same information is deeply, irretrievably, wrong.
agree with you 100%. KISS is indeed an operative principle with ISO. We did understand that and made sure that a) we identified a single entity as our client (the fact that we serve others is just a function of serving the client.) for example, 'the client' for Amazon's IT infrastructure people can be viewed as the business people that run the 'store', not the individual customers. The metric to the business people is store uptime. b) We were able to provide a single number to represent collective performance of hundreds of systems. and it is a number that we already had lying around. I said management is always asking for metrics, I didn't say I was answering each request with a new metric... You take them in, you chew on them, you try to work stuff out. Sometimes you can respond with "that's complicated to implement, and here is why." Other times you can provide something existing that will work. Once in a while, you go to your employees and get a feel for what they think might work, then you chew some more.
If employees can't figure it out, what makes you think a manager, with less understanding of the work, will be able to to a decent job? There are extremes to everything, asking about paper clip flow, or putting a password on the photocopier are often counter-productive measures. but in this situation, it is hard to say what is actually going on. In general, a manager asking employees for metrics is just plain smart.
The manager is looking for input. If what you say makes sense, and he can use it, you get appreciation, and your productivity gets measured in a way of your choosing, and hopefully the manager gets buy in from the staff that the metrics make sense and the work of automatically making reports happens smoothly. First, there is a fashion going around about everything being measurable. There is a good chance that he is being asked by his boss to provide metrics. So if you help your boss on this, it could very well help everyone. Second, 9 times out of 10, a manager's status is based on his budget and the number of employees managed. a manager asking you for metrics could easily be looking for ways to justify new hiring to boost him.
Do nothing, and the manager is stuck inventing a metric that is clueless. You can then bitch about it, and his response will be (if you're lucky): "what's wrong with it, how can we improve it?" in which case you are stuck answering the same question, just being stuck with a sucky metric for a few months, and pissing off your boss for not having answered in the first place. The alternative manager answer might be "Tough, I asked, and acted on the feedback I got, I had to supply a metric by this date, and so you are stuck with it until the next planning cycle (year? 5 years? who knows)?"
A good manager is someone who is trying to understand what his people do and leverage them to get more stuff done. At the same time, a manager wants to make sure that others in the organization know about what his team does. Flashy pie charts of productivity are a way to do that. Sure, like everything, it can go wrong, but asking his employees is doing the smart thing, hopefully the employees will use this as an opportunity to implement something that will help them (like trouble tracking) and at the same time generate statistics for free as a side effect.
(yeah, I'm a line manager, and yeah, my bosses (the higher you go, the more you have) regularly ask for productivity measures as part of ISO 9000 compliance, and yeah, it's really hard, and yeah, the right answer depends on what your business is.)
search linux payroll software yes, I know HR is more than payroll, but you know... if the payroll modules work well it is kind of an important indicator...
mod parent up. You tap the data streams in and out of the VM, it is much easier for to get at the content from software.
In the end though, what nasty person is going to pay attention to a eula? The first hack is going to be to patch so that vista doesnt recognize that it is in a VM.
then the warez/pirate folk will go on their merry way...
This will only affect casual piracy, and fair use (as usual.)
Article is way off the mark because it does not take into account the different corporate goals... MS is not "open" because it is licensing it's DRM, it is simply fulfilling the extend and extinguish and platform hegemony objectives...
MS is licensing an entire platform, so having their DRM on every possible platform is already a goal. They only need to license binaries for the platforms they support already (Windows, mobile, etc...)
Apple if they want to license to non-Apple platforms has two un-palatable choices: Distribute as source, or support binaries on all kinds of unknown platforms (ie. Symbian, linux, Palm, in addition to all the MS flavours.) It's clearly in complete opposition to Apple's strategy of controlling the platform to provide the best end user experience.
It is unusual in that it sounds to me like a company that "gets it". The company likely just wants to use the code in their business, but is not in the software business. Amazon was an early contributor to apache, because they needed a web server to run their business.
I have been in a situation where the only software available for a business need cost in the middling six digit territory, and managed to replace this application with some about 10000 lines of python scripting. Do I want to sell this application? It is not my business (we are not even a development shop, not enough of a team, need marketing, etc...) Do I want to maintain it forever? If I open source it, there is a chance that outside people will help. If we keep it in-house, we are just condemned to supporting it forever. It does not cost us anything to use a public svn repository, people have to get to whatever the development process is.
The company could be making widgets, and just need software that runs them. This could be a driver, or it could be some packaging around a linux distro for some appliance. 99% of the code would be GPL in such a case, maintaining the 1% contributed by this guy would likely just make for bad publicity if they only release the 99%.
For a new deployment, you have to take into account what is in place, what are the weaknesses, and how they are being addressed by the new thingum. google around for household names with breaches like so:
That article talks about basic things like establishing a perimeter. IF your company does not have a decent DMZ defined,and proper safeguards wrt Intrusion detection, and properly walling off remote services. If people are sending credit card information via telnet, then you probably want to work on security. A gadget rarely solves anything. security is 99% about people and processes because you have to cover all the bases. The bad guys just have to find one weakness.
Well, there you see you are demonstrating the problem afflicting so many of our youth today. If the proposal is accepted, no-one will have your problem in the future. While preventing problems for future generations, we need to be sensitive to those who face challenges such as yours today. those who are most unfortunately afflicted with being born on the day between 12 and 14 could refer to their birth day as the '12B' of a month, and have the option of celebrating on either the 12th or 14th. In the modern world, there are many cases of reconstituted family units. Such options would permit one to celebrate with one side of the family on the twelfth, and the other on the fourteenth, which will give each side a increase feeling of self-worth.
Timezones have outlived their usefulness. They were a great improvement over every village setting it's time as before timezones existed, but nowadays, you never know when something is on tv (except using an electronic program guide) and there is so much long distance interaction (ie. tech support in India, R&D division in China, etc...) that telling time has become a real hassle. If you work in a company of any scope, there are lots of meetings, and many are missed because people didn't notice the timezone, or even if they did, miscalculated the difference between their timezone and this one. Working in Canada, have to deal with: Newfoundland, Atlantic, Eastern, central, Saskatchewan (and a few cities either east or west of it that adopted the no-DST rule) mountain, and pacific time zones.
It would be a heck of a lot easier if folks would just, at a state/province, or some sort of regional level, decided that stores open at 14 Z in the winter, and 13Z in the summer (corresponding to 9am Eastern time, including DST) Store hours are already mandated, so just mandate that they change summer and winter, but do not change how people count. Define 'Local Standard winter hours' and 'Local standard summer hours.' Do not change the clocks, change the times...
I would rather do away with DST entirely, but if you must do it, it should not be done by changing the time, but rather by changing the hours, and keeping time straightforward. The best would be to forget about DST and timezones entirely, and for everyone to adopt UTC.
Out of deference to the events in 2001, the number 911 should be reserved for unique use (in North America) of the emergency services telephone number, it's use in all other contexts... 13 could be included in the ban to standardize current practices. Most high rises do not have a thirteenth floor, and Friday the 13th would cease to be a problem. No price, by law, for any item will ever be 13 or 911 dollars, except on march 13th (except when that would fall on a friday, in which case it would be a slip year), and September 11th, when those prices will be allowed. No use of the numbers 13 or 911 will be permitted in architectural or engineering diagrams of any kind, for fear offending those who lost loved ones on that terrible day.
The impact on counting should be very minor, as I personally lived in an apartment on 12B for many years, and there was no cost to this. A few if statements here and there. Sure, there are some complications, Look, for example at the daylight savings time, how simple it is to understand that on some days of the year, there are 23 hours, (where there is no 3:12 am.) and on others, there are 25 hours (where there are two 3:12 am's.) but only in some places, sometimes, depending on what the local government says.
It is great to change how people count... dollars, dimensions, hours, to serve political or societal goals. It makes life better for everyone. Much simpler than changing prices or opening hours to serve them. All we need to do is pass a law, and change the way we count. Simple and practical so that no one has to keep track.
It's worse than that, it really is high in nuisance value because they removed all the binary blobs, so practically no wireless hardware and assorted other peripherals, and virtually no multimedia, will just plain not work. This is new distro would have significant nuisance value if people try it out and then find that "nothing works."
-- The trivial 'hack' is to jam communications, which is basically a DOS. My assumption is that robots will have basic self-defense capabilities and autonomy when their communicatons are hacked. They will continue as ordered, much like a cruise missile today, without radio guidance, will head to target using GPS. If the GPS fails, it will continue on inertial systems. If their orders are to 'hold the base' they will fire on whatever approaches them. etc... -- You do not need to be on the battlefield to hack into systems, being on the battlefield will not be of much use to you if systems are hacked, since your robots will turn on you, and you will not have any better access to the hackers for being physically present. Yeah... just go ahead and try to reach the off switch... -- if they can hack into the robots, they can hack the Command and Control, so they can:
-- give bogus orders or information to humans just as much as to robots.
-- mess with IFF so have Friendly units bomb eachother. --. If you really get hacked, you are screwed, period. Cyber defenses, to prevent getting hacked will be very important, but you do not need body armour for that, and there is no privileged physical location for it. -- normal situation (non-hacked) --- a force fielding 100 robots against 1 human... what is the human going to be able to do that the 100 robots cannot? Even if there is something that the human can do, what government, given the choice of sending in 100 robots, with no political fallout if it is lost, is going to send in 1 human? If robots are even basically able to do the job, people are going to want them to do it. Military work is clearly Dull,Dirty and Dangerous... a perfect traditional application for robotics. -- If you are stuck policing a crowd, like in Iraq... Wouldn't it be fabulous to lose a couple of robots to a mad crowd, rather than kill twenty iraqis and maybe lose a helicopter while trying to extract one or two guys who got cut-off? Look at all the problems with Truck drivers being ambushed. That's why DARPA is funding robots that can drive.
Look this is supposed to come online in what... fifteen to twenty years? By that time, ''soldiers'' will be sitting in Pods in Idaho, controlling swarms of robots walking around Iraq (Yes, they US will probably still be there...) The concept of putting humans in dangerous situations will be as alien as putting humans inside a nuclear reactor is today.
We've got robots driving themselves ( http://www.grandchallenge.org/ ) and many, many robots that are starting to walk effectively, and simultaneous translation is coming along... There will be things that look like ceylons, walking around, and when something interesting happens, a human will start looking at what it sees... There is little point in developing next generation battlefield kit for humans. Our destiny is to be civilians. The soldier will cease to exist, and the supervision might be outsourced from Idaho to pods in India at 1$/hour.
That can be good, for folks who want to control large populations like in iraq with little risk. It's just as convenient for small oligarchies to control large populations, such as in Russia, Burma, China, etc... The demand will be so great that initially high costs will come down rapidly.
It's kind of an inevitable result of current developments. The main question is what non-oligarchs should be doing it about it...
I appreciate your sentiment, and I wish you the best, but I think you are... well, very optimistic... Checkout my dapper -> Edgy upgrade stories in my Journal. They arent smooth. They arent rocket science, but by and large, normal people would not get through it. So you are signing up to be the sole source of tech support for all your friends and family. Thats very generous, if you tell people to do something and they do it, after that time, anything that happens to any of those computers is going to be your fault... machine no longer has a power light? Must be that new fangled ubutnu thingum... Call Jake... This game doesnt install? Call Jake... For every single one of those problems folks are going to say... I dont understand this ubutnu thing because they cannot go to BestBuy and have the friendly teenagers there change the power supply because... "Ubuntu, we dont support that?!"
It isnt like there is anything wrong with Kubuntu. I run it almost exclusively and love it. It is truly great linux distribution, and a very easy (in comparison to other linux distributions.) thing to use. The problem here is the network effect. Everyone uses windows, so everyone supports windows, so everyone uses windows. I dont know how to fix that. I keep hoping that MS could develop some really effective copy protection for MS-Office, so that folks at home actually start paying the legitimate prices for it. That would provide an eye opener
I hope you can make it work for your friends and family, to help break the network effect, but be prepared for a lot of work.
We were using MimeDefang + SA for a while, but it wasnt enough. Second the vote for Canit... just (as in Wednesday) rolled out Canit/PRO to serve mailboxes for 5000 full-time employees. Works well, cost is very reasonable. It has the benefit of the centralized solution for reduced maintenance, but we can use the web interface to customize mail flows for people with particular needs.
The problem is that there is no way to know the quality of the counterfeit. Is it the same? What if the shielding is no good because they left out some of that expensive metal, or they used components in their power supplies that work really well for 10,000 hours, then explode, or have double the power drain of a normal component. What about using the wrong processor chip, so that firmware sort of works but does not really, because the hardware is not the revision it claims to be. Any and all of those things will get back to the name brand vendor in terms of support costs, and potential liability. It will be upto the vendor to demonstrate that the gear is, in fact, counterfeit. For the client, look at the potential hassle (oh.. why does that breaker keep tripping, and why is that rack warmer than the rest, how come that 3452 works like this, but the other one doesn't.)
Life is complicated enough without being lied to. Brand name is about QA and support so that you can have some faith in the equipment, especially if you have 25 others of the same model. A client who gets counterfeit has neither benefit.
"unbounded development only works if software isn't your primary source of revenue."
true. however, that is the more general case.
Most programmers are not google material and do not work in places which sell software. Their clients are usually internal. If you can get your client to co-operate, or have the client in charge, and they understand well, and give them short term incremental features, it can work. The problem with software development is the sheer size of the 'unknown' portion in any estimate. When you get too many requirements, too many stake holders, too many commitments, and too many people watching, it is a recipe for 'challenges' and makes life really hard for the developers. There is a fundamental dichotomy: If you need funding, you have to sell, if you sell, you need to offer people something they want. Lesson: Try to get by with very little funding. I know this sounds trite, but it argues for component re-use, gradual accretion of a toolset, less development, and more thought about using existing components.
My preference is to is to undersell, underpromise, be modest and flexible about delivery dates, and use the absolute minimum amount of resources. The less resources being spent on a particular deliverable, the more management will leave you alone. You have your own long term strategy in mind, and cherry pick deliverables that you can meet at each step along the way... At any point you can point to recent successes, and planned next steps.
The overall plan, being years long, does not need to be shared widely because it is vapour anyways, will probably never happen, and if it does happen will be changed beyond all recognition. It is just a framework on which to hang current work. Best not to let people know that it even exists. If you start sharing it, then folks will say... well I want X but that's way down the list, and you end up changing the plan to meet deliverables, rather than picking deliverables that you can meet along the plan.
It really helps to have a small budget/number of stake holders, a clear understanding of the problem to be solved overall and at each step, which leads naturally to aggressively limiting scope, and incremental delivery.
Slashdot Mirror
I would add that it is the assertion that is specious. This is slashdot, no-one implies anything when they can just assert it outright.
They switched their store systems over... http://www.novell.com/success/burlington.html
I bet this is their desktops in back offices and such.
perhaps this will be 'inspiring' to them to finish the job.
FitPC has USB.
-- You can add a usb wifi peripheral to turn it into an Access Point.
http://www.cdw.com/shop/products/default.aspx?EDC=785329
-- add a usb/ethernet
for a DMZ with three ethernets...
usb ethernet example: http://www.amazon.com/Belkin-F5D5050-Networking-Ethernet-Adaptor/dp/B000062R4P
disclaimer: I just googled, no idea about linux compatibility of these particular devices.
USB makes this completely flexible...
On point 4 you are without a scintilla of clue.
...
... Again, you have just invented apt-get/aptitude/yum.
The problem is as follows:
You package has dependencies. It requires the version of glibc and a dozen other libraries you built it with. Do you talk to the developers of glibc and the dozen other libraries? if they want to upgrade their libraries what do you do?
If you want to be independent then you take a copy of glibc that you used to build your app. you install it it in its own appdir so your app can use it. You do that for each of your dozen dependencies. Then you are independent.
Benefits:
-- your app is independent.
costs:
-- no shared library usage because every application is going to want its own copy of twelve libraries.
-- massive disk space cost because every application is going to
-- large number of copies of the same f2#@%#! library on the system is usually pointless.
-- this is how windows works, and their term for this situation is DLL hell because you have no clue
which version of a particular DLL is being used by any application.
Now lets say there is a security problem in glibc. You can either:
a) tell your users to screw off, they paid for software and you gave it to them, two year old glibc and all. Security is somebody elses problem.
b) be out of business, in which case refer ex-customers to a)
c) have a server available for your customers to download patches from. Those patches will include patches to all the libraries which you depend on. So you have to validate and produce packages for all
of the twelve libraries which you depend on. You maintain complete packaging, including all dependencies, for each and every distribution you support. You are able to, on request, verify which packages need updating, and perform coherent updates (perhaps multiple dependencies have to be updated together with your application in order for it all to work together.)
Congratulations! you are now running a repository with dependency management. One step further and you can have your own distro.
Of course, you could avoid that by simply listing in the requirements for the software all the library versions they must have (which is fine, unless they feel the need to upgrade their OS at some point, and your app breaks.) but then that forces the user to use repository tools to satisfy dependencies... hmm... why not automate that by having the application know what its dependencies are!
The alternative is to cultivate package maintainers for various distros, let them maintain the packages for the distributions, let them understand the weirdnesses of each one and help you with packaging issues.
Use them as filters for bug reports, so that if the problem is distro specific, they look at it first.
All applications use the same glibc (and any other common dependency) saving huge amounts of disk and memory space. Now when a new glibc patch comes out, the build cluster will automatically re-compile your package if needed and any other dependencies against it, and your clients will automatically received (a single copy of) the patched glibc, and the patched application, with zero effort on your part. If you are getting weird problem reports from a particular distro, talk to the packager and try to work it out together. build a relationship, dont swear about his existence. You are wrong, life is not simple, and swearing at people that reveal that it is more complicated than you would like to believe is stupid.
The second reason you are lacking in vision is that you pretend that there is some bright line between the OS and applications. Get a f$#% clue! to the guy writing BIND or djbdns, DNS is an application. in the 1980s, berkeley networking was an optional application stack on
That sucks big time. heres why:
First. It mixes in meta-data with data. Metadata should be somewhere else, because, well obviously, if I have 1500 configuration files for slight variations of the same thing, then Im going to have 1499 pointless copies of metadata. keep the validation information and real data separate, dammit.
Second. XML parsing is 10 to 100 times slower than parsing a text file. You have clearly never written a text file parser and an XML parser. Using a reasonable language like python, text file parsing is trivial.
XML parsing is simply not to be attempted without a library, its that painful. When you are going to read 10,000 config files, it matters. If you adopt this scheme widely, you will end up reading that large number of files. XML structure doesnt add anything useful. It is not easier to read than a standard text file. It is not more concise. It will be expensive.
Third. when upgrading your software, all the metadata can change, If you want to upgrade and see what the differences are... good luck! Comments, upper bounds, etc... will all change. Keeping meta data separate from configuration, allows you to diff the meta data separately from the configuration info.
Fourth. I18n and i10n. If you wanted to do your approach thoroughly, you would have 150 translations of all the textual meta data in the same file. That file is going to be one big sucker. Put it in a separate file? fine. do it consistently instead of treating one language as special.
Fifth. If you have All this XML meta data in a separate file and the text file stays in exactly the same format, you still get all the goodness, and you havent lost anything. The only requirement for this is to have a couple of text file parsers. There are not that many flavours of such text file formats, so some XML tag could identify the grammar approach. The text file, concise, to the point, easily parsed by experienced humans, remains untouched.
Sixth: you completely miss the point of text files. They are a user interface. To me, a text file with a simple, easy to understand grammar, together with an application that identifies format errors is the easiest, most flexible, most effective way to manage application configuration. I regularly strip out comments from configuration files because to me, 99% of the comments are noise. If I wanted documentation on the format, I would look in a man page. Configuration information is a list of settings.
The point of text files is that they are human editable, human auditable, diffable, revision controllable. When you make the file format too noisy for a human to parse, you lose the entire benefit of a text file in the first place. It might as well be binary, because no human can safely edit the file anymore (Its too !@%#$@! complicated to edit the file and get all the tags and metadata correct.) The user of a text configuration file is a human. Making him type, or understand five times or ten times as much text to configure the same information is deeply, irretrievably, wrong.
agree with you 100%. KISS is indeed an operative principle with ISO.
We did understand that and made sure that
a) we identified a single entity as our client (the fact that we serve others is just a function of serving the client.) for example, 'the client' for Amazon's IT infrastructure people can be viewed as the business people that run the 'store', not the individual customers. The metric to the business people is store uptime.
b) We were able to provide a single number to represent collective performance of hundreds
of systems. and it is a number that we already had lying around.
I said management is always asking for metrics, I didn't say I was answering each request with a new metric... You take them in, you chew on them, you try to work stuff out. Sometimes you can respond with "that's complicated to implement, and here is why." Other times you can provide something existing that will work. Once in a while, you go to your employees and get a feel for what they think might work, then you chew some more.
If employees can't figure it out, what makes you think a manager, with less understanding of the work, will be able to to a decent job? There are extremes to everything, asking about paper clip flow, or putting a password on the photocopier are often counter-productive measures. but in this situation, it is hard to say what is actually going on. In general, a manager asking employees for metrics is just plain smart.
The manager is looking for input. If what you say makes sense, and he can use it, you get appreciation, and your productivity gets measured in a way of your choosing, and hopefully the manager gets buy in from the staff that the metrics make sense and the work of automatically making reports happens smoothly. First, there is a fashion going around about everything being measurable. There is a good chance that he is being asked by his boss to provide metrics. So if you help your boss on this, it could very well help everyone. Second, 9 times out of 10, a manager's status is based on his budget and the number of employees managed. a manager asking you for metrics could easily be looking for ways to justify new hiring to boost him.
Do nothing, and the manager is stuck inventing a metric that is clueless. You can then bitch about it, and his response will be (if you're lucky): "what's wrong with it, how can we improve it?" in which case you are stuck answering the same question, just being stuck with a sucky metric for a few months, and pissing off your boss for not having answered in the first place. The alternative manager answer might be "Tough, I asked, and acted on the feedback I got, I had to supply a metric by this date, and so you are stuck with it until the next planning cycle (year? 5 years? who knows)?"
A good manager is someone who is trying to understand what his people do and leverage them to get more stuff done. At the same time, a manager wants to make sure that others in the organization know about what his team does. Flashy pie charts of productivity are a way to do that. Sure, like everything, it can go wrong, but asking his employees is doing the smart thing, hopefully the employees will use this as an opportunity to implement something that will help them (like trouble tracking) and at the same time generate statistics for free as a side effect.
(yeah, I'm a line manager, and yeah, my bosses (the higher you go, the more you have) regularly ask for productivity measures as part of ISO 9000 compliance, and yeah, it's really hard, and yeah, the right answer depends on what your business is.)
search linux payroll software yes, I know HR is more than payroll, but you know... if the payroll modules work well it is kind of an important indicator...
timetrex.com
http://www.paythyme.com/
then there a about a dozen sponsored links...
mod parent up. You tap the data streams in and out of the VM, it is much easier
for to get at the content from software.
In the end though, what nasty person is going to pay attention to a eula?
The first hack is going to be to patch so that vista doesnt recognize that it is in a VM.
then the warez/pirate folk will go on their merry way...
This will only affect casual piracy, and fair use (as usual.)
here is an /etc/network/interfaces entry for WPA which worked
7 2617abvc9113
for me on Ubuntu Edgy Eft, and Debian Etch.
iface eth2 inet dhcp
wpa-driver wext
wpa-key-mgmt WPA-PSK
wpa-group TKIP
wpa-ssid yourSSID
wpa-psk 61599e462342933eae6ec3c478d15ec2551cae5591123cc83
Article is way off the mark because it does not take into account the different corporate goals... MS is not "open" because it is licensing it's DRM, it is simply fulfilling the extend and extinguish and platform hegemony objectives...
MS is licensing an entire platform, so having their DRM on every possible platform is already a goal. They only need to license binaries for the platforms they support already (Windows, mobile, etc...)
Apple if they want to license to non-Apple platforms has two un-palatable choices: Distribute as source, or support binaries on all kinds of unknown platforms (ie. Symbian, linux, Palm, in addition to all the MS flavours.) It's clearly in complete opposition to Apple's strategy of controlling the platform to provide the best end user experience.
It saves in odt or word, you just save locally, and then upload when you get back into a bandwidth pool.
It is unusual in that it sounds to me like a company that "gets it". The company likely just wants to use the code in their business, but is not in the software business. Amazon was an early contributor to apache, because they needed a web server to run their business.
I have been in a situation where the only software available for a business need cost in the middling six digit territory, and managed to replace this application with some about 10000 lines of python scripting. Do I want to sell this application? It is not my business (we are not even a development shop, not enough of a team, need marketing, etc...) Do I want to maintain it forever? If I open source it, there is a chance that outside people will help. If we keep it in-house, we are just condemned to supporting it forever. It does not cost us anything to use a public svn repository, people have to get to whatever the development process is.
The company could be making widgets, and just need software that runs them. This could be a driver, or it could be some packaging around a linux distro for some appliance. 99% of the code would be GPL in such a case, maintaining the 1% contributed by this guy would likely just make for bad publicity if they only release the 99%.
For a new deployment, you have to take into account what is in place, what are the weaknesses, and how they are being
r ucture/33200565-b133-4eed-8c05-c6f35f8f60b6.html
addressed by the new thingum. google around for household names with breaches like so:
http://www.itworldcanada.com/a/Enterprise-Infrast
That article talks about basic things like establishing a perimeter. IF your company does not have a decent DMZ defined,and proper
safeguards wrt Intrusion detection, and properly walling off remote services. If people are sending credit card information via telnet, then you probably want to work on security. A gadget rarely solves anything. security is 99% about people and processes because you have to cover all the bases. The bad guys just have to find one weakness.
you just check off "numerically challenged" on the form. We will probably add a new category to
the affirmative action directives.
Well, there you see you are demonstrating the problem afflicting so many of our youth today.
If the proposal is accepted, no-one will have your problem in the future. While preventing problems
for future generations, we need to be sensitive to those who face challenges such as yours today. those who are most unfortunately afflicted with being born on the day between 12 and 14 could refer to their birth day as the '12B' of a month, and have the option of celebrating on either the 12th or 14th. In the modern world, there are many cases of reconstituted family units. Such options would permit one to celebrate with one side of the family on the twelfth, and the other on the fourteenth, which will give each side a increase feeling of self-worth.
peace be upon you.
Timezones have outlived their usefulness. They were a great improvement over every village setting it's time as before timezones existed, but nowadays, you never know when something is on tv (except using an electronic program guide) and there is so much long distance interaction (ie. tech support in India, R&D division in China, etc...) that telling time has become a real hassle. If you work in a company of any scope, there are lots of meetings, and many are missed because people didn't notice the timezone, or even if they did, miscalculated the difference between their timezone and this one. Working in Canada, have to deal with: Newfoundland, Atlantic, Eastern, central, Saskatchewan (and a few cities either east or west of it that adopted the no-DST rule) mountain, and pacific time zones.
It would be a heck of a lot easier if folks would just, at a state/province, or some sort of regional level, decided that stores open at 14 Z in the winter, and 13Z in the summer (corresponding to 9am Eastern time, including DST) Store hours are already mandated, so just mandate that they change summer and winter, but do not change how people count. Define 'Local Standard winter hours' and 'Local standard summer hours.' Do not change the clocks, change the times...
I would rather do away with DST entirely, but if you must do it, it should not be done by changing the time, but rather by changing the hours, and keeping time straightforward. The best would be to forget about DST and timezones entirely, and for everyone to adopt UTC.
Out of deference to the events in 2001, the number 911 should be reserved for unique use (in North America) of the emergency services telephone number, it's use in all other contexts... 13 could be included in the ban to standardize current practices. Most high rises do not have a thirteenth floor, and Friday the 13th would cease to be a problem. No price, by law, for any item will ever be 13 or 911 dollars, except on march 13th (except when that would fall on a friday, in which case it would be a slip year), and September 11th, when those prices will be allowed. No use of the numbers 13 or 911 will be permitted in architectural or engineering diagrams of any kind, for fear offending those who lost loved ones on that terrible day.
The impact on counting should be very minor, as I personally lived in an apartment on 12B for many years, and there was no cost to this. A few if statements here and there. Sure, there are some complications,
Look, for example at the daylight savings time, how simple it is to understand that on some days of the year, there are 23 hours, (where there is no 3:12 am.) and on others, there are 25 hours (where there are two 3:12 am's.) but only in some places, sometimes, depending on what the local government says.
It is great to change how people count... dollars, dimensions, hours, to serve political or societal goals. It makes life better for everyone. Much simpler than changing prices or opening hours to serve them. All we need to do is pass a law, and change the way we count. Simple and practical so that no one has to keep track.
It's worse than that, it really is high in nuisance value because they removed all the binary blobs, so practically no wireless hardware and assorted other peripherals, and virtually no multimedia, will just plain not work. This is new distro would have significant nuisance value if people try it out and then find that "nothing works."
It is a real gnuisance.
-- The trivial 'hack' is to jam communications, which is basically a DOS. My assumption is that robots will have basic self-defense capabilities and autonomy when their communicatons are hacked. They will continue as ordered, much like a cruise missile today, without radio guidance, will head to target using GPS. If the GPS fails, it will continue on inertial systems. If their orders are to 'hold the base' they will fire on whatever approaches them. etc...
-- You do not need to be on the battlefield to hack into systems, being on the battlefield will not be of much use to you if systems are hacked, since your robots will turn on you, and you will not have any better
access to the hackers for being physically present. Yeah... just go ahead and try to reach the off switch...
-- if they can hack into the robots, they can hack the Command and Control, so they can:
-- give bogus orders or information to humans just as much as to robots.
-- mess with IFF so have Friendly units bomb eachother.
--. If you really get hacked, you are screwed, period. Cyber defenses, to prevent getting hacked will be very important, but you do not need body armour for that, and there is no privileged physical location for it.
-- normal situation (non-hacked) --- a force fielding 100 robots against 1 human... what is the human going to be able to do that the 100 robots cannot? Even if there is something that the human can do, what government, given the choice of sending in 100 robots, with no political fallout if it is lost, is going to send in 1 human? If robots are even basically able to do the job, people are going to want them to do it. Military work is clearly Dull,Dirty and Dangerous... a perfect traditional application for robotics.
-- If you are stuck policing a crowd, like in Iraq... Wouldn't it be fabulous to lose a couple of robots
to a mad crowd, rather than kill twenty iraqis and maybe lose a helicopter while trying to extract one
or two guys who got cut-off? Look at all the problems with Truck drivers being ambushed. That's why DARPA is funding robots that can drive.
It's completely inevitable.
Look this is supposed to come online in what... fifteen to twenty years? By that time, ''soldiers'' will be sitting in Pods in Idaho, controlling swarms of robots walking around Iraq (Yes, they US will probably still be there
We've got robots driving themselves ( http://www.grandchallenge.org/ ) and many, many robots that are starting to walk effectively, and simultaneous translation is coming along... There will be things that look like ceylons, walking around, and when something interesting happens, a human will start looking at what it sees... There is little point in developing next generation battlefield kit for humans. Our destiny is to be civilians. The soldier will cease to exist, and the supervision might be outsourced from Idaho to pods in India at 1$/hour.
That can be good, for folks who want to control large populations like in iraq with little risk.
It's just as convenient for small oligarchies to control large populations, such as in Russia, Burma, China, etc... The demand will be so great that initially high costs will come down rapidly.
It's kind of an inevitable result of current developments. The main question is what non-oligarchs should be doing it about it...
I appreciate your sentiment, and I wish you the best, but I think you are... well, very optimistic...
Checkout my dapper -> Edgy upgrade stories in my Journal. They arent smooth. They arent rocket science, but by and large, normal people would not get through it. So you are signing up to be the sole source of tech support for all your friends and family. Thats very generous, if you tell people to do something and they do it, after that time, anything that happens to any of those computers is going to be your fault... machine no longer has a power light? Must be that new fangled ubutnu thingum... Call Jake... This game doesnt install? Call Jake... For every single one of those problems folks are going to say... I dont understand this ubutnu thing because they cannot go to BestBuy and have the friendly teenagers there change the power supply because... "Ubuntu, we dont support that?!"
It isnt like there is anything wrong with Kubuntu. I run it almost exclusively and love it. It is truly great linux distribution, and a very easy (in comparison to other linux distributions.) thing to use. The problem here is the network effect. Everyone uses windows, so everyone supports windows, so everyone uses windows. I dont know how to fix that. I keep hoping that MS could develop some really effective copy protection for MS-Office, so that folks at home actually start paying the legitimate prices for it. That would provide an eye opener
I hope you can make it work for your friends and family, to help break the network effect, but be prepared for a lot of work.
We were using MimeDefang + SA for a while, but it wasnt enough. Second the vote for Canit... just (as in Wednesday) rolled out Canit/PRO to serve mailboxes for 5000 full-time employees. Works well, cost is very reasonable. It has the benefit of the centralized solution for reduced maintenance, but we can use the web interface to customize mail flows for people with particular needs.
The problem is that there is no way to know the quality of the counterfeit. Is it the same?
What if the shielding is no good because they left out some of that expensive metal, or they used components in their power supplies that work really well for 10,000 hours, then explode, or have double the power drain of a normal component. What about using the wrong processor chip, so that firmware sort of works but does not really, because the hardware is not
the revision it claims to be. Any and all of those things will get back to the name brand vendor in terms of support costs, and potential liability. It will be upto the vendor to demonstrate that the gear is, in fact, counterfeit. For the client, look at the potential hassle (oh.. why does that breaker keep tripping, and why is that rack warmer than the rest, how come that 3452 works like this, but the other one doesn't.)
Life is complicated enough without being lied to. Brand name is about QA and support so that you can have some faith in
the equipment, especially if you have 25 others of the same model. A client who gets counterfeit has neither benefit.
"unbounded development only works if software isn't your primary source of revenue."
true. however, that is the more general case.
Most programmers are not google material and do not work in places which sell software. Their clients are usually internal. If you can get your client to co-operate, or have the client in charge, and they understand well, and give them short term incremental features, it can work. The problem with software development is the sheer size of the 'unknown' portion in any estimate. When you get too many requirements, too many stake holders, too many commitments, and too many people watching, it is a recipe for 'challenges' and makes life really hard for the developers. There is a fundamental dichotomy: If you need funding, you have to sell, if you sell, you need to offer people something they want. Lesson: Try to get by with very little funding. I know this sounds trite, but it argues for component re-use, gradual accretion of a toolset, less development, and more thought about using existing components.
My preference is to is to undersell, underpromise, be modest and flexible about delivery dates, and use the absolute minimum amount of resources. The less resources being spent on a particular deliverable, the more management will leave you alone. You have your own long term strategy in mind, and cherry pick deliverables that you can meet at each step along the way... At any point you can point to recent successes, and planned next steps.
The overall plan, being years long, does not need to be shared widely because it is vapour anyways, will probably never happen, and if it does happen will be changed beyond all recognition. It is just a framework on which to hang current work. Best not to let people know that it even exists. If you start sharing it, then folks will say... well I want X but that's way down the list, and you end up changing the plan to meet deliverables, rather than picking deliverables that you can meet along the plan.
It really helps to have a small budget/number of stake holders, a clear understanding of the problem to be solved overall and at each step, which leads naturally to aggressively limiting scope, and incremental delivery.