Hmm, my instant thought was similiar, but a little bit different:
"What the hell did they manage to do before, so that they thought they'd could also get this through?"
You are not going from zero to full speed when starting playing dirty. You start small, next time you get a little bit more couragous, and each time more. You either stop increasing the risk at one point, or you'll get caught eventually.
The question is, what kind of ploys have been done by the jokers responsible for this before, and didn't get noticed???
Many people here commented that you can't measure productivity of a Sysadmin. This sort of misses the point. And to keep maintaining this stance of "what we are doing cannot be put in numbers" in a huge company will ultimately lead to job cuts in the IT Operations departments if times get tougher, money has to be saved, and heads will be counted. Because everybody else (Marketing, Finance etc.) *will* have numbers at hand to show how "productive" they are and how they cannot spare even one FTE. Add to that that companies like IBM are knocking on the door of your CIO everyday with nice slides showing how IT Operations outsourcing will cut his costs and risk. You cannot argument against that with the handwaving I'm reading around here.
I work for a big telecommunications provider, and their Service Assurance department have strong KPIs and process cost numbers running. The first thing you / your company will have to do is to have unified processes for operations (look up ITIL Service Management in google) - if something like this isn't in place already.
Then define clearly, together with management, what you want to measure (and maybe optimize as a result of your measurements). Probably you want to measure total cost of ownership of your IT infrastructure, based on standards, and compare that. Make also clear that individual productivity is not what is really important, but measuring the result of this is. For example, the number of time you solve a problem in production is not important... the cumulative time needed for this is, but not for measuring your personal productivity, but to measure how much time you are needing for fixing things compared to prevent thing compare to just do maintainance work (in ITIL Terms: Incident vs. Change vs. Problem Mgmt. time).
Together with this initiative, your direct management needs to make blatantly clear to upper management that the productivity / effiency of the individual is only measurable by them, i.e. by direct assessment of your personal skill etc.
That way, you show as a group that you are willing to work transparently, while at the same time making that your future existance within the company is more secure.
Last word: We in IT really have to face the fact that it was our stance of "trust us, you cannot understand our value for the company anyway" has helped in making outsourcing so attractive for PHBs, because it gives them the ability to replace us with something they (believe to) understand: a simple contract.
It probably wasn't the technical barriers. Believe me, Mobile Operators drop huge loads of money into new services, they are always in desperate need of new "killer" services. This visual voicemail thing is a good addition, and it is probably quite cheap to deploy. It should be doable with just a software update on the existing voicemail infrastructure - very cheap compared to other services.
What probably made the iPhone not attracive enough should be the commercial demands apple made, like the rumor that they get a part of the revenue - this is something much more expensive for the carrier than just building up minor technical infrastructure.
maybe the problem is, that a scripted POST should not be allowed. I for one don't see a valid reason for the browser to allow a submit method on forms with the method POST.
I'm sure this was also not in the intention of the authors of this respective RFC, because they actually a browser to follow a 301, 302 redirect for instance.
I was not talking about python vs. C++! Clearly, C++ wins here in number of applications its based on. I was criticizing what you said, repeated here for your convenience:
"There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary."
See? It's not about Python vs. C++, per your own words. Btw. WoW uses TCL in the backend, Battlefield 2 has python hooked in for scripting, where you can script _everything_, not only GUI events. Skype/Windows is developed in Pascal/Delphi.
Major applications where at least GUI events are not directly handled in C++: Azureus, Eclipse (Java), Mozilla/Firefox/Thunderbird (GUI=XUL + Javascript), All newer MS Apps (which are or will be C#). How many fingers do you have?
What you see is as soon as people want something which is easily extendable, they are going to get they GUI done in higher level languages. C, C++ will remain for the really performance critical tasks, if needed, but non of the real GUI stuff and most of the other stuff is of that nature.
There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary.
I call bullshit as long as you don't back this up with numbers. They point is, even in C++ you are normally using the (native) bindings to you GUI library of choice. That means that the dominating factor for speed of the GUI is the speed of the GUI library, because in most cases your backend code will not be time intensive. In Python/Perl/Ruby etc. you will also use bindings, therefore speed will compare.
Btw. C++ for the GUI is eaten alive by Java/C# and the combination of scripting languages + GUI widgets, so others seem to disagree, too.
Try to express outrage in a foreign language (while you are outraged), and you'll maybe understand. In that situation, you want to get steam off, and you don't seek for words that long. It plausible that he hadn't said "nuke" in his mother tongue.
You know, they have to make money. And buying JBoss is a very good move, IMO. Because if they offer bundled support contracts, there is a big opportunity for JBoss to gain market share.
And their reference to SOA is right on, there's a big move forward in the Enterprise to put Application Servers as a SOA glue layer in front of legacy application. And that is one thing where open source is very strong.
It always seems like automatically filling in username and password would lead to some exploit, but I can't think of a case where this has happened. Since I don't read security reports with my breakfast, can anyone who does think of a instance?
Wifes standing behind their husbands while the browser automatically fills in the password for fsckingteens.com. Makes pretending he visited this site by mistake a little bit harder.
You are aware that these sites don't need to store *anything* in the cookie besides a unique key for the user? They then pull out with that key everything they want from a database, independend from the cookie size.
That leaves us with a)web designers being complete morons, or b)site being composed of different web applications which all have their own demands for certain cookies to be set. For instance main site app server + some web statistics software serving one image and a cookie + some add serving software serving another image and another cookie.
Maybe it's easier and more reliable to analyze the binaries of a complete built. Let's say they have legacy binaries leftover from NT 4 or 98 or whatever, which, during development of newer windows versions, got ported by inserting conditional compile-time includes etc.
But I have to say that I still get the same impression as you have, reading the interview I'm surprised about the huge amount of complexity they have in their system compared to for instance linux. For instance it sounds like they have a whole team doing the work of someone like Ingo Molnar and maybe one or two other developers on linux. And from what I read, they aren't even ahead of linux concerning this soft RT stuff for multimedia. The reason might very well be also the huge complexity of the system they are working on.
I know of three major reasons why people don't use OpenOffice...
I know a fourth one:
Warezing. Many people don't have to decide between paying hundreds for MS Office and the free Open Office, because they are using an illegal copy of MS Office. If people's only choice was between living with some incompatilites or shelling out that much money, many would decide different.
MUFFDIVER.COM.XXX and MUFFDIVE.NET.XXX if they really want to keep their old TLD strings? Yes, I know that means reserving TLD.XXX, but that shouldn't be a problem.
This is called Process Design. Often in companies and big organisations, the Process Managers or Process Designers are people not working in these processes once they are in place. They just sit there, dreaming up nice theories about how things could be more efficient or measurable - KPIs, "You can't manage what you can't measure" and other bullshit is what you hear from them.
After that, a software is build to fit their strange requirements. Sooner or later, this software meets reality, i.e. real users which will have to live the processes and maybe introduced their own shortcuts and simplifications, which now won't work anymore, because the new software doesn't allow them.
Big discussions arise, the Process Managers fingerpoint to IT because the system is not doing what the Users expected (it's doing what the Process Managers specified though, but that doesn't help).
If the deviation is too big, the system get's thrown away.
Hey, I didn't mean to implied that everything related to encryption is snake oil;).
It's just that most people forget that with some careful analysis, there are indeed ways to avoid having to store data in plaintext on the system. Or encrypted with a key which is available on the system anyway, which is - as you said - as secure as storing plaintext.
And that the alternative is just securing the publically reachable server with firewalls, keep up to date with security fixes and stuff and hope your defense is good enough.
The key IMO is a combination of encryption and network security, and I bet that you can use a system like I outlined above in many cases.
and more importantly, database encryption is mostly snake oil. usually if a hacker get to your database, he found your application first, and he has the key to decrypt your super-secure-2048bit-encrypted-database.
Absolutely - if you do it with one key for all. I once had to design such a system, and started by looking at scenarious on how what information from the db had to be available clear text, and more importantly, to whom. What I came up with was using two dbs. One driving the front end to the users, storing the sensitive per-user data encrypted with the user's password, and a hash of the password for authentication. The second database would be totally disconnected from the system, holding the data unencrypted for usage by us, and only receiving updates from the frontend when necessary (User updates his record), and that in real time. There was no (implemented) way to get data back from the second db to the frontend system. So even if an attacker roots the frontend system+db, he's only able to get at the data of users logging in at that time.
That way I think we miniminzed the timespan when unencrypted data exists at all in the frontend system.
I could even do without a cd at all! I mean, a CD doesn't have the artistic touch of vinyls anyway, and CDs are getting less and less important for the typical consumer, because the way we catalogue and store our media at home and in the car is rapidly transitioning towards centralized server applications. I'd have no problem paying 5 bucks for downloading a CD worth of high quality mp3s, maybe with a little artwork to display on a media center screen or something.
They don't necessarily need to be out of business. A large part of what they do currently is give small musicians the benefit of their hugeness. They give them "loans" so that they can record with good equipment and with professional producers. At home you can record with no producers and with, at best, ok equipment. They promote the band. Advertise its shows and its albums. Also very expensive and very difficult to do without a record company. And of course, they distribute the music, as well as band merchandise. This can be in the form of CD's, as currently, or it could be in the form of getting mp3s on Itunes or even setting up free distribution channels. This would also be very expensive without a record company.
If you take the classic distribution channels out, like getting the CDs to the big department store chains, there's nothing in what you describe above which couldn't be done by Amazon, Google, Microsoft, Apple etc. It's done in smaller dimensions today already, but imagine Google or Amazon throwing their knowledge of datamining the behavior of individual users and using it to find "relevant" products (i.e. music titles) to this field in a big way. This combined with them offering mp3 downloads. The classic core competency of record companies (distribution) is not only totally made obsolete, but they also add something where Sony et al. have nothing to bring on the table.
I'd say if Amazon wasn't still dependend on good relationships to the legacy music industry and google wasn't busy targeting microsoft, one of them reviving the mp3.com idea could really hurt the music industry.
The nice thing is that all this DRM crap will lessen their chances even more in the long run, because makes their product less attractive and other big players with alternative offers will eventually surface.
What needs to happen is that a big star will have to surface who is not already bound with contracts to the record industry.
If you want to see the future, go over to allofmp3 dot com, look here for an example..
Slashdot Mirror
Hmm, my instant thought was similiar, but a little bit different:
"What the hell did they manage to do before, so that they thought
they'd could also get this through?"
You are not going from zero to full speed when starting playing dirty.
You start small, next time you get a little bit more couragous,
and each time more. You either stop increasing the risk at
one point, or you'll get caught eventually.
The question is, what kind of ploys have been done by the jokers
responsible for this before, and didn't get noticed???
Many people here commented that you can't measure productivity of a Sysadmin.
...
This sort of misses the point. And to keep maintaining this stance of "what we
are doing cannot be put in numbers" in a huge company will
ultimately lead to job cuts in the IT Operations departments if times get tougher,
money has to be saved, and heads will be counted. Because everybody else
(Marketing, Finance etc.) *will* have numbers at hand to show how "productive"
they are and how they cannot spare even one FTE.
Add to that that companies like IBM are knocking on the door of your CIO everyday
with nice slides showing how IT Operations outsourcing will cut his costs and risk.
You cannot argument against that with the handwaving I'm reading around here.
I work for a big telecommunications provider, and their Service Assurance
department have strong KPIs and process cost numbers running.
The first thing you / your company will have to do is to have unified processes
for operations (look up ITIL Service Management in google) - if something
like this isn't in place already.
Then define clearly, together with management, what you want to measure (and maybe
optimize as a result of your measurements).
Probably you want to measure total cost of ownership of your IT infrastructure,
based on standards, and compare that.
Make also clear that individual productivity is not what is really important,
but measuring the result of this is. For example, the number of time you
solve a problem in production is not important
the cumulative time needed for this is, but not for measuring
your personal productivity, but to measure how much time you are needing for
fixing things compared to prevent thing compare to just do maintainance work
(in ITIL Terms: Incident vs. Change vs. Problem Mgmt. time).
Together with this initiative, your direct management needs to make blatantly
clear to upper management that the productivity / effiency of the individual
is only measurable by them, i.e. by direct assessment of your personal skill etc.
That way, you show as a group that you are willing to work transparently, while
at the same time making that your future existance within the company is more secure.
Last word: We in IT really have to face the fact that it was our stance of
"trust us, you cannot understand our value for the company anyway" has helped
in making outsourcing so attractive for PHBs, because it gives them the ability
to replace us with something they (believe to) understand: a simple contract.
"Either you are part of the solution, or you are part of the problem." ... I hate that saying
It probably wasn't the technical barriers. Believe me, Mobile Operators drop huge
loads of money into new services, they are always in desperate need of new
"killer" services. This visual voicemail thing is a good addition, and it is
probably quite cheap to deploy. It should be doable with just a software update
on the existing voicemail infrastructure - very cheap compared to other services.
What probably made the iPhone not attracive enough should be the commercial
demands apple made, like the rumor that they get a part of the revenue - this
is something much more expensive for the carrier than just building up minor
technical infrastructure.
Yeah,
maybe the problem is, that a scripted POST should not be allowed.
I for one don't see a valid reason for the browser to allow a submit
method on forms with the method POST.
I'm sure this was also not in the intention of the authors of this
respective RFC, because they actually a browser to follow
a 301, 302 redirect for instance.
I was not talking about python vs. C++! Clearly, C++ wins here in number of applications its based on. I was criticizing what you said, repeated here for your convenience:
"There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary."
See? It's not about Python vs. C++, per your own words.
Btw. WoW uses TCL in the backend, Battlefield 2 has python hooked in for scripting, where you can script _everything_, not only GUI events. Skype/Windows is developed in Pascal/Delphi.
Major applications where at least GUI events are not directly handled in C++: Azureus, Eclipse (Java), Mozilla/Firefox/Thunderbird (GUI=XUL + Javascript), All newer MS Apps (which are or will be C#). How many fingers do you have?
What you see is as soon as people want something which is easily extendable, they are going to get they GUI done in higher level languages. C, C++ will remain for the really performance critical tasks, if needed, but non of the real GUI stuff and most of the other stuff is of that nature.
There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary.
I call bullshit as long as you don't back this up with numbers. They point is, even in C++ you are normally using the (native) bindings to you GUI library of choice. That means that the dominating factor for speed of the GUI is the speed of the GUI library, because in most cases your backend code will not be time intensive.
In Python/Perl/Ruby etc. you will also use bindings, therefore speed will compare.
Btw. C++ for the GUI is eaten alive by Java/C# and the combination of scripting languages + GUI widgets, so others seem to disagree, too.
Try to express outrage in a foreign language (while you are outraged),
and you'll maybe understand. In that situation, you want to get steam off,
and you don't seek for words that long. It plausible that he hadn't said
"nuke" in his mother tongue.
You know, they have to make money. And buying JBoss is a very good move, IMO. Because if they offer bundled support contracts, there is a big opportunity for JBoss to gain market share.
And their reference to SOA is right on, there's a big move forward in the Enterprise to put Application Servers as a SOA glue layer in front of legacy application. And that is one thing where open source is very strong.
Whatever happens, we should all try our best to support MySQL in what may be a losing battle against an evil foe.
When they put their money where there mouth is, like trolltech did a long time ago, I'll start supporting them.
Summary:
MySQL is used by the ignorant masses swayed by marketing hype and lies
Ah!
That's the reason Oracle is buying its way into Mysql land, they are going after
their customer base!
Heh, we are reading "stuff that matters".
Nobody gets fired for that!
It always seems like automatically filling in username and password would lead to some exploit, but I can't think of a case where this has happened. Since I don't read security reports with my breakfast, can anyone who does think of a instance?
Wifes standing behind their husbands while the browser automatically fills in the password for fsckingteens.com. Makes pretending he visited this site by mistake a little bit harder.
You are aware that these sites don't need to store *anything* in the cookie besides a unique key for the user?
They then pull out with that key everything they want from a database, independend from the cookie size.
That leaves us with
a)web designers being complete morons, or
b)site being composed of different web applications which all have their own demands for certain cookies to be set.
For instance main site app server + some web statistics software serving one image and a cookie + some add serving software serving another image and another cookie.
Maybe it's easier and more reliable to analyze the binaries of a complete built.
Let's say they have legacy binaries leftover from NT 4 or 98 or whatever, which,
during development of newer windows versions, got ported by inserting conditional
compile-time includes etc.
But I have to say that I still get the same impression as you have, reading the interview
I'm surprised about the huge amount of complexity they have in their system compared
to for instance linux.
For instance it sounds like they have a whole team doing the work of someone
like Ingo Molnar and maybe one or two other developers on linux. And from what
I read, they aren't even ahead of linux concerning this soft RT stuff for multimedia.
The reason might very well be also the huge complexity of the system they are working on.
First is the cost; while we don't have to 'pay' for OOo, I will be pushing for a donation to the project
Better yet, put some money back in case you want to pay someone to add features you need or fix bugs.
I know of three major reasons why people don't use OpenOffice...
I know a fourth one:
Warezing.
Many people don't have to decide between paying hundreds for MS Office and the free Open Office, because they are using an illegal copy of MS Office.
If people's only choice was between living with some incompatilites or shelling out that much money, many would decide different.
MUFFDIVER.COM.XXX and MUFFDIVE.NET.XXX if they really want to keep their old TLD strings?
Yes, I know that means reserving TLD.XXX, but that shouldn't be a problem.
Absolutely.
This is called Process Design.
Often in companies and big organisations, the Process Managers or
Process Designers are people not working in these processes once they
are in place. They just sit there, dreaming up nice theories about how things
could be more efficient or measurable - KPIs, "You can't manage what you can't
measure" and other bullshit is what you hear from them.
After that, a software is build to fit their strange requirements. Sooner or
later, this software meets reality, i.e. real users which will have to
live the processes and maybe introduced their own shortcuts and simplifications,
which now won't work anymore, because the new software doesn't allow them.
Big discussions arise, the Process Managers fingerpoint to IT because
the system is not doing what the Users expected (it's doing what the
Process Managers specified though, but that doesn't help).
If the deviation is too big, the system get's thrown away.
Hey, I didn't mean to implied that everything related to encryption is snake oil ;).
It's just that most people forget that with some careful analysis, there are indeed
ways to avoid having to store data in plaintext on the system. Or encrypted with a key which is
available on the system anyway, which is - as you said - as secure as storing plaintext.
And that the alternative is just securing the publically reachable server with firewalls,
keep up to date with security fixes and stuff and hope your defense is good enough.
The key IMO is a combination of encryption and network security, and I bet that
you can use a system like I outlined above in many cases.
and more importantly, database encryption is mostly snake oil. usually if a hacker get to your database, he found your application first, and he has the key to decrypt your super-secure-2048bit-encrypted-database.
Absolutely - if you do it with one key for all.
I once had to design such a system, and started by looking at scenarious on how what information from the db had to be available clear text, and more importantly, to whom.
What I came up with was using two dbs. One driving the front end to the users, storing the sensitive per-user data encrypted with the user's password, and a hash of the password for authentication.
The second database would be totally disconnected from the system, holding the data unencrypted for usage by us, and only receiving updates from the frontend when necessary (User updates his record), and that in real time.
There was no (implemented) way to get data back from the second db to the frontend system.
So even if an attacker roots the frontend system+db, he's only able to get at the data of users logging in at that time.
That way I think we miniminzed the timespan when unencrypted data exists at all in the frontend system.
Sorry, just to give this post more visibility, because Denim is actually very great.
I could even do without a cd at all!
I mean, a CD doesn't have the artistic touch of vinyls anyway, and CDs are getting less and less important for the typical consumer, because the way we catalogue and store our media at home and in the car is rapidly transitioning towards centralized server applications.
I'd have no problem paying 5 bucks for downloading a CD worth of high quality mp3s, maybe with a little artwork to display on a media center screen or something.
They don't necessarily need to be out of business. A large part of what they do currently is give small musicians the benefit of their hugeness. They give them "loans" so that they can record with good equipment and with professional producers. At home you can record with no producers and with, at best, ok equipment. They promote the band. Advertise its shows and its albums. Also very expensive and very difficult to do without a record company. And of course, they distribute the music, as well as band merchandise. This can be in the form of CD's, as currently, or it could be in the form of getting mp3s on Itunes or even setting up free distribution channels. This would also be very expensive without a record company.
If you take the classic distribution channels out, like getting the CDs to the big department store chains, there's nothing in what you describe above which couldn't be done by Amazon, Google, Microsoft, Apple etc.
It's done in smaller dimensions today already, but imagine Google or Amazon throwing their knowledge of datamining the behavior of individual users and using it to find "relevant" products (i.e. music titles) to this field in a big way. This combined with them offering mp3 downloads. The classic core competency of record companies (distribution) is not only totally made obsolete, but they also add something where Sony et al. have nothing to bring on the table.
I'd say if Amazon wasn't still dependend on good relationships to the legacy music industry and google wasn't busy targeting microsoft, one of them reviving the mp3.com idea could really hurt the music industry.
The nice thing is that all this DRM crap will lessen their chances even more in the long run, because makes their product less attractive and other big players with alternative offers will eventually surface.
What needs to happen is that a big star will have to surface who is not already bound with contracts to the record industry.
If you want to see the future, go over to allofmp3 dot com, look here for an example..
Sorry, this should mean "at its base". I hate when I do this.