There might be a few guys who really hate Microsoft, but most of us are just sick of having to use their crap
Close, but no cigar.
Most (non techie) people hate M$ because it's what runs their computers.
While everybody on slashdot would heartily agree that those computers are running a crap os and applications, the core of the problem is that people are taught that they do not have to understand or learn how their computer works. This is complete nonsense and always leads to disaster. Just a basic knowledge of the concepts of file, folder, application, network, disk, ram and cpu would do a lot to help.
I tested MacOSX for grandpa and grandma: while I found it incredibly more consistent, stable and polished that most microsoft apps, they managed to run it into the ground (just by never having learned how to close an application. Startup time skyrocketed and the whole gui got slow as a sleeping turtle because the poor beast was running all the time all the apps...)
So go ahead and check out a large company running macs: users will tell you the os is crap, unstable and slow. Do not even try to feed linux to the masses.
If computers where as simple to operate as a tv set and never had any evolution at all in their interfaces, people would love them.
ps: the fact that MS might be responsible for educating the users to not understand computers is another matter...
In most of the 'xml as hierarchical data storage' usage cases, JSON is what-it-should-have-been since the beginning (basically, ini files with nested structures): - no element vs. attribute headaches - no element-with-data-inside vs. element with elements inside headaches - no way to declare external entities, cdata sections and other obscure features - freaking easier to parse - specs out very clearly charset encoding and escape sequences maybe we'll have a post from Tim about that in a couple of years...
The laser based barcode readers used in airport BHSs are usually 6 sided scanning tunnels
This does not prevent a few (a lot?) of the baggages to go misread, and end up on the line to the guy-with-a-barcode-scanner-in-his-hand queue. Afaik, rfid has lower error rates. Plus, I think the huge 6-sides readers cost more than the rfid reader does (that's why it's usual that many barcode readers deployed on the circuit are the lower-end 3 or 4-sided ones).
On a conveyor line, reading multiple RFID tags at the same time is a problem
It is true that on a conveyor belt reading many tags at a time is in fact a disadvantage, but it helps in almost every other part of the process, such as eg. baggage reconciliation when bags are counted again and matched to embarked passengers just before being loaded into the plane.
Most of the current BHS systems which use RFID only have a unique license plate on the RFID tag
It's a bit of a shame, really...
The worst part is when we first evaluated the system a couple of years back, the bigger single obstacle we found was nobody (airline, airport, handler) was willing to put up with the extra price of the rfid tag (read 1 dollar per tag)...
Airports have been experimenting with this since at least 2001, and many are using it in production.
Contrary to what some posters assumed, rfid DOES in fact help quite a bit the baggage handling system:
- rfid reader can read tags which sit on the bottom / opposite end of the suitcase, while barcode readers cannot do it. The overall positive-read ratio is much increased. The tags are smaller and less prone to tear-off/smearing of the barcode print
- rfid card readers can read many tags at a time, hence the conveyor line can be sped up a lot (as in: put all baggages on the truck to the runaway, and the rfid reader is put on top of the gate below which the truck passes)
- if the complete baggage info, such as final destination, status of x-ray-check, etc is stored on the tag (there are quite a few bytes in there), any tag reader can decode it and sort the baggage even in the absence of network connection , ie . without interrogating a central db. Smaller devices, not even wifi-connected, can be used to recover info from baggages that are found stray in any airside area (and a working 802.11 inside a bhs system or covering a complete runaway is radio nightmare,trust me). Downside: if that info is not crypted, it could be eavesdropped...
Of course, the point is still valid that all the new anti-terrorism measures are quite a nightmare for airports and airline handlers, and have a great impact on operative efficiency.
Oh yeah......and then the flashy new app gets released to us, based on Oracle Mapviewer producing SVG files. At one meg every file, do you think you can discard: - the time spent gzipping it server-side - the time spent dezipping it client-side - the ungodly amount of RAM it chews up on every single client - the sheer computing time the client needs to parse the xml into in-memory structures, render and blit them them to screen? I tell you I cannot: the resulting interaction is slooooooow. The sw developer is still undecided if we will have to upgrade our network to gigabit or replace every single client with workstation-class hardware with a fast video card.
BTW: oracle is moving fast out of SVG and into ajax-based UI, copying 100% of what google did a couple of years ago: jscript+png/jpeg...
A little while ago somebody did a speed comparison test on xml vs. binary format for speradhseet files. The result was: Office+xml is comparable to openoffice+xml, but the shit is beaten out of both by using the native binary format (2 megs file vs 11 meg once in memory or something like that)...
...and all the legit cell phones go off screaming!
was it the final scene of the lawnmoverman? or did they copy the idea from some idiotic scheme for configuring atm machines?
As of 2006 Italian police is also deploying some of those, eg. to policemen patrolling inside railway stations. Maybe not a huge success, but they're still in business...
That's why I never set ZoneAlarm to let IE to the internet: - use FF only as everyday web browser - when doing windows update or visiting the occasional borked site, 'allow IE for this time only'
Of course you could script other tools like wget or curl to get to the web, but not many people would set those to 'always trusted', unless they are also used by some commercial app used on a daily basis.
This is a moot point anyway, since I fully agree with the opition expressed many times above, that Joe User has no clue at all about what to let through and what to forbid, when the question pops up. ZA for example gives only the exe file name, which is a very poor hint, but even adding full directory, timestamp, exe version and such would not be of any help, let alone be dependable.
Sorry pal, large organization called. They're still using windows 2000 as their (main) desktop OS, cuz' they don't want to spend big bucks on upgrading hardware, retraining users, re-testing all internal apps etc...
Oh, and I forgot to mention: win2k SP4 fully patched IS exploitable.
BTW: I really like how the MS blog downplays the role of 'HTTP 1.1' enabled (which is the default on fresh IE installs) and HTTP compression used (which is what about every single site in the world does)
At our place, sysadmins went crazy over all the VMWARE capabilities.
The benfeits are indeed huge, including cutting os intall times to virtually few seconnds, moving live servers from one box to another in case of hw failure, taking server snapshots before upgrading, etc...
What they forgot to think about is that using one virtual server dedicated to every single app (instead of consolidating many apps inside a single os) comes with many downsides, too, esp. on windows:
- licensing costs explode, taking into account AV sw, backup sw, mgmt sw licences
- virtualization eats little cpu per se, but try run 5 AV processes, 5 tivoli/openview/landesk/whatever management client processes on one box, and cpu is toast
- backing up complete server images instead of simple sets of file will easily saturate your lan and storage devices
etc...
all in all it's cool enough, but it comes with many drawbacks, too.
The funny thing is all corporate networks that have no windows domain fully deployed yet will be in big trouble, unless the admins deploy some extra security policy that switches back intranet sites to the local zone. Otherwise no activeX, stuff will get broken, etc...
(from the IE blog: only pc;'s connected to a domain will have a local zone enabled)
Looks more like a ploy to force all corporate users to move to active directory asap...
But I had a SQL Server on a windows cluster, that consistently crashed the shared-storages scsi controller when trying to execute a backup, sending junk down both data and log files.
The fault was probably in the scsi controller firmware, but I really was left wondering what kind of low-low-level disk commands the sql backup mechanism used to move its data around... especially considering that, being cluster-aware, the db refused to use any storage device but the shared ones for stroing backup data!
A couple of points missing from the above setup:
- each and every device must have double power sources, linked to 2 separate power grids, possibly by different energy vendors (we just had the power failing at airport XXX server room last week, right after the cable guys had spent 6 months convincing us to migrate all servers to the 'new' power lines)
- the entire network path from server to end users should be duplicate. What about the super-solid cluster lan being connected to end-user lan via a single pof (e.g. firewall)?
Jokes aside, real HA is real hard. There's always a little single point of failure hidden somewhere that you forgot. And gettim them all duplicate costs $$$$ and then $$$$ more
...even when all the parties involved cooperate in the most good willed manner. And I know it form first hand experience.
Let's say a researcher found a bug in quite commonly used open source network protocol lib. The bug has been sitting there for about four years, despite public availability of the code and widespread usage. Maybe the black hats know it, maybe they do not: no single hacking incident has been reported (yet) involving the lib in question.
Now the reseracher contacts the maintainer, and a fix is available and tested, in under 3 days.
One of the vendors of the involved apps, privately contacted, decides to go public without coordinating with the rest of the community: they publish the disclosure and the fix. The lib maintainer is forced to publish the upstream fix ASAP, and give it as much publicity as possible. So does the rearcher. All other app vendors react wonderfully quickly, and realase patched versions within 1 to 2 weeks.
You'd think all is fine with this, the speed and coordination of the Good Guys - Open Source Model having been proven yet one more time? WRONG!
After yet two more weeks, one quite high profile website gets hacked because of not having applied the patch to the app running the site, and its admins get a lot of bad press and foul mouthing on/.
And yet, rant all you want about incompetent programmers and idiotic sysadmins, it had not happpened in the previous FOUR years, and would possibly not have happened at all without the work of the security researcher!
Moral of the story is: sometimes events take an unexpected twist. Do not blame corporations/vendors for not always doing the 'right thing' asap: the implicatons could be more subtle and far reaching than what is apparent.
Cygwin - lets you use bash scripting plus the complete bag
PHP can directly manipulate COM objects, which is very convenient for working with MS Office files, Acrobat and a lot of other windows sw. I guess Python has it too, and possibly even Perl.
WPDFD was mostly about teaching to designers the stuff the coders (should) know.
It made a very interesenting read for developers, too: gaining insight into the point of view of people you have to collaborate with is extermely useful, and something that developers tend to underestimate a lot.
It also was useful in a pure 'development' perspective: lots of info about web design, html/js best practices, tool reviews and such.
All in all, I think the point is it's sometimes very hard to draw the line between web designer and veleoper.
First of all, thanks for turning my bunch of chars into something readable. I had been writing it in a haste with 5 people shouting at me to go to lunch. And sorry for this lame excuse, tooo.
Now, for some more content:
JBOSS: it might be free and open and be the coolest app of the year too, my boss will prefer buying BEA anyday just coz it has a big ENTERPRISE sticker on the box. I can imagine there are some more savvy IT managers somewhere in the world, I have still to meet them (in large organizations at last)
(PS. Hire me any day )
app server are not webservers True, and still the apps being served are not based on CORBA, COM or web-services offereted to fat clients: the apps are served as HTML. And in html images are used quite a lot...
About J2EE being used for for stuff more complicated than shopping carts: altough this us very true in theory, in practice most web apps I have seen end up being shopping-cart-like.
Rationale: There might be a lot of business logic involved in the app, but the front-end always ends up looking like win XP: overly simple, with a small number of large, coloured buttons. I tend to blame it on http and its request-response paradigm rather than the language used to code the BL: there is e.g. still no standard way to have a drop down box reload its values from the server when an event happens in the UI. And user input validation still has to be done twice, both in JS client-side (to be kind to users) and in JAVA/PHP/SQL server-side (to be tough to tampererers)
I could rephrase that as: the impedance mismatch exists, and it is between web frontends and java.
presentation logic changes faster than business logic: a typeless, 'sloppy' language is usually faster to use for accomodating changing requirements
html presentation logic is all about cobbling togerther a bunch of strings: a functional language with strong regexp capabilities is more suited than one where all Strings are objects
most Java frameworks I have seen tend to subvert the HTTP paradigm in order to accomodate basic stuff such as auth, session, persistence. But in the end they tend to get MORE complicated to use than the problems they were aiming for in the first place: subtle bugs pop-in because there are too many layers involved, becuase the developer, coding in an event-driven paradigm, did not think about the user hitting the F5 or BACK button and so on.
All in all: despite the original blog postings being at least 75% marketroid speak, I am pretty convinced that app servers are mostly used today as
sledgehammmers for nut cracking. And I am willing to give some credit to people that present something new.
FACT 1: J2EE is overengineered for everything, and darn too complex to learn.
I'm not talking solely about EJB, just take a look at all the frameworks springing up every year, JSP, JSF, STRUTS, more than you can poke an acronym at. If anything, the emerging terns is: all the frameworks are solving the wrong problem.
FACT 2: JVM might be getting faster with JIT and all, but Java AS suck RAM big time (and CPU too). BEA advises customers to use open-source technology (Apache) to server static content, cuz' it would kill the server. And their product costs $$$, while Apache is free.
FACT 3: PHP+Apache+(insert favorite DB) is no toy at all. PHP actually is running the internet far more than java has ever been. It would me a mistake to ignore scripting languages on the premises that MySQL does not support transactions/stored procedures / whatever.
HINT 1: J2EE only has it place in big enterprises that are willing to get it becuase the big bucks it costs come with some big name company that offers support. Big enterproses still are unwilling to bet the house on 'get-it-from-newsgroups-on-google' tech support.
HINT 2: the same big companies are very much likely to use Oracle, Sybase or DB2 for the DB back-end. But if they do, they already paid for the possibility to write all the business logic inside the DB, and have it running better and faster than in the applicatio-tier.
HINT 3: even in enterprise contexts, the largest part of the majority of apps is pretty stupid form entry and validation. The presentation logic changes much faster than the data. And scripting languages are faster to write presentation logic than JAVA or dotNot.
HINT 4: horizontal scaling is gonna be big. Real DB and PHP gurus know it can beat AS clustering anytime.
OK, just my 2cents of flaming...
Slashdot Mirror
Close, but no cigar.
Most (non techie) people hate M$ because it's what runs their computers.
While everybody on slashdot would heartily agree that those computers are running a crap os and applications, the core of the problem is that people are taught that they do not have to understand or learn how their computer works. This is complete nonsense and always leads to disaster. Just a basic knowledge of the concepts of file, folder, application, network, disk, ram and cpu would do a lot to help.
I tested MacOSX for grandpa and grandma: while I found it incredibly more consistent, stable and polished that most microsoft apps, they managed to run it into the ground (just by never having learned how to close an application. Startup time skyrocketed and the whole gui got slow as a sleeping turtle because the poor beast was running all the time all the apps...)
So go ahead and check out a large company running macs: users will tell you the os is crap, unstable and slow. Do not even try to feed linux to the masses.
If computers where as simple to operate as a tv set and never had any evolution at all in their interfaces, people would love them.
ps: the fact that MS might be responsible for educating the users to not understand computers is another matter...
In most of the 'xml as hierarchical data storage' usage cases, JSON is what-it-should-have-been since the beginning (basically, ini files with nested structures):
- no element vs. attribute headaches
- no element-with-data-inside vs. element with elements inside headaches
- no way to declare external entities, cdata sections and other obscure features
- freaking easier to parse
- specs out very clearly charset encoding and escape sequences
maybe we'll have a post from Tim about that in a couple of years...
It is true that on a conveyor belt reading many tags at a time is in fact a disadvantage, but it helps in almost every other part of the process, such as eg. baggage reconciliation when bags are counted again and matched to embarked passengers just before being loaded into the plane.
It's a bit of a shame, really... The worst part is when we first evaluated the system a couple of years back, the bigger single obstacle we found was nobody (airline, airport, handler) was willing to put up with the extra price of the rfid tag (read 1 dollar per tag)...
Airports have been experimenting with this since at least 2001, and many are using it in production.
Contrary to what some posters assumed, rfid DOES in fact help quite a bit the baggage handling system:
- rfid reader can read tags which sit on the bottom / opposite end of the suitcase, while barcode readers cannot do it. The overall positive-read ratio is much increased. The tags are smaller and less prone to tear-off/smearing of the barcode print
- rfid card readers can read many tags at a time, hence the conveyor line can be sped up a lot (as in: put all baggages on the truck to the runaway, and the rfid reader is put on top of the gate below which the truck passes)
- if the complete baggage info, such as final destination, status of x-ray-check, etc is stored on the tag (there are quite a few bytes in there), any tag reader can decode it and sort the baggage even in the absence of network connection , ie . without interrogating a central db. Smaller devices, not even wifi-connected, can be used to recover info from baggages that are found stray in any airside area (and a working 802.11 inside a bhs system or covering a complete runaway is radio nightmare,trust me).
Downside: if that info is not crypted, it could be eavesdropped...
Of course, the point is still valid that all the new anti-terrorism measures are quite a nightmare for airports and airline handlers, and have a great impact on operative efficiency.
Oh yeah... ...and then the flashy new app gets released to us, based on Oracle Mapviewer producing SVG files.
At one meg every file, do you think you can discard:
- the time spent gzipping it server-side
- the time spent dezipping it client-side
- the ungodly amount of RAM it chews up on every single client
- the sheer computing time the client needs to parse the xml into in-memory structures, render and blit them them to screen?
I tell you I cannot: the resulting interaction is slooooooow.
The sw developer is still undecided if we will have to upgrade our network to gigabit or replace every single client with workstation-class hardware with a fast video card.
BTW: oracle is moving fast out of SVG and into ajax-based UI, copying 100% of what google did a couple of years ago: jscript+png/jpeg...
A little while ago somebody did a speed comparison test on xml vs. binary format for speradhseet files. The result was: Office+xml is comparable to openoffice+xml, but the shit is beaten out of both by using the native binary format (2 megs file vs 11 meg once in memory or something like that)...
...and all the legit cell phones go off screaming! was it the final scene of the lawnmoverman? or did they copy the idea from some idiotic scheme for configuring atm machines?
As of 2006 Italian police is also deploying some of those, eg. to policemen patrolling inside railway stations.
Maybe not a huge success, but they're still in business...
That's why I never set ZoneAlarm to let IE to the internet:
- use FF only as everyday web browser
- when doing windows update or visiting the occasional borked site, 'allow IE for this time only'
Of course you could script other tools like wget or curl to get to the web, but not many people would set those to 'always trusted', unless they are also used by some commercial app used on a daily basis.
This is a moot point anyway, since I fully agree with the opition expressed many times above, that Joe User has no clue at all about what to let through and what to forbid, when the question pops up.
ZA for example gives only the exe file name, which is a very poor hint, but even adding full directory, timestamp, exe version and such would not be of any help, let alone be dependable.
Sorry pal, large organization called. They're still using windows 2000 as their (main) desktop OS, cuz' they don't want to spend big bucks on upgrading hardware, retraining users, re-testing all internal apps etc...
Oh, and I forgot to mention: win2k SP4 fully patched IS exploitable.
BTW: I really like how the MS blog downplays the role of 'HTTP 1.1' enabled (which is the default on fresh IE installs) and HTTP compression used (which is what about every single site in the world does)
At our place, sysadmins went crazy over all the VMWARE capabilities.
The benfeits are indeed huge, including cutting os intall times to virtually few seconnds, moving live servers from one box to another in case of hw failure, taking server snapshots before upgrading, etc...
What they forgot to think about is that using one virtual server dedicated to every single app (instead of consolidating many apps inside a single os) comes with many downsides, too, esp. on windows:
- licensing costs explode, taking into account AV sw, backup sw, mgmt sw licences
- virtualization eats little cpu per se, but try run 5 AV processes, 5 tivoli/openview/landesk/whatever management client processes on one box, and cpu is toast
- backing up complete server images instead of simple sets of file will easily saturate your lan and storage devices
etc...
all in all it's cool enough, but it comes with many drawbacks, too.
Darn, I knew I should have never married a math teacher!
The funny thing is all corporate networks that have no windows domain fully deployed yet will be in big trouble, unless the admins deploy some extra security policy that switches back intranet sites to the local zone. Otherwise no activeX, stuff will get broken, etc...
(from the IE blog: only pc;'s connected to a domain will have a local zone enabled)
Looks more like a ploy to force all corporate users to move to active directory asap...
There's also a nice product from Quest software (Shareplex?) that works along the same line of Oracle Dataguard.
Dunno which one is cheaper, though...
Nice one.
But I had a SQL Server on a windows cluster, that consistently crashed the shared-storages scsi controller when trying to execute a backup, sending junk down both data and log files.
The fault was probably in the scsi controller firmware, but I really was left wondering what kind of low-low-level disk commands the sql backup mechanism used to move its data around... especially considering that, being cluster-aware, the db refused to use any storage device but the shared ones for stroing backup data!
A couple of points missing from the above setup:
- each and every device must have double power sources, linked to 2 separate power grids, possibly by different energy vendors (we just had the power failing at airport XXX server room last week, right after the cable guys had spent 6 months convincing us to migrate all servers to the 'new' power lines)
- the entire network path from server to end users should be duplicate. What about the super-solid cluster lan being connected to end-user lan via a single pof (e.g. firewall)?
Jokes aside, real HA is real hard. There's always a little single point of failure hidden somewhere that you forgot. And gettim them all duplicate costs $$$$ and then $$$$ more
...even when all the parties involved cooperate in the most good willed manner. And I know it form first hand experience.
Let's say a researcher found a bug in quite commonly used open source network protocol lib. The bug has been sitting there for about four years, despite public availability of the code and widespread usage. Maybe the black hats know it, maybe they do not: no single hacking incident has been reported (yet) involving the lib in question. Now the reseracher contacts the maintainer, and a fix is available and tested, in under 3 days. One of the vendors of the involved apps, privately contacted, decides to go public without coordinating with the rest of the community: they publish the disclosure and the fix. The lib maintainer is forced to publish the upstream fix ASAP, and give it as much publicity as possible. So does the rearcher. All other app vendors react wonderfully quickly, and realase patched versions within 1 to 2 weeks.
You'd think all is fine with this, the speed and coordination of the Good Guys - Open Source Model having been proven yet one more time? WRONG! /.
After yet two more weeks, one quite high profile website gets hacked because of not having applied the patch to the app running the site, and its admins get a lot of bad press and foul mouthing on
And yet, rant all you want about incompetent programmers and idiotic sysadmins, it had not happpened in the previous FOUR years, and would possibly not have happened at all without the work of the security researcher!
Moral of the story is: sometimes events take an unexpected twist. Do not blame corporations/vendors for not always doing the 'right thing' asap: the implicatons could be more subtle and far reaching than what is apparent.
- Python
- PHP
- Perl
- UnxUtils
- Cygwin - lets you use bash scripting plus the complete bag
PHP can directly manipulate COM objects, which is very convenient for working with MS Office files, Acrobat and a lot of other windows sw. I guess Python has it too, and possibly even Perl.WPDFD was mostly about teaching to designers the stuff the coders (should) know.
It made a very interesenting read for developers, too: gaining insight into the point of view of people you have to collaborate with is extermely useful, and something that developers tend to underestimate a lot.
It also was useful in a pure 'development' perspective: lots of info about web design, html/js best practices, tool reviews and such.
All in all, I think the point is it's sometimes very hard to draw the line between web designer and veleoper.
Now, for some more content:
I could rephrase that as: the impedance mismatch exists, and it is between web frontends and java.
Off to install Zope...
notimetotypeineasymarkuplanguagebeforetwohundredco mmentsgetposted,sorry:)
FACT 1: J2EE is overengineered for everything, and darn too complex to learn. I'm not talking solely about EJB, just take a look at all the frameworks springing up every year, JSP, JSF, STRUTS, more than you can poke an acronym at. If anything, the emerging terns is: all the frameworks are solving the wrong problem. FACT 2: JVM might be getting faster with JIT and all, but Java AS suck RAM big time (and CPU too). BEA advises customers to use open-source technology (Apache) to server static content, cuz' it would kill the server. And their product costs $$$, while Apache is free. FACT 3: PHP+Apache+(insert favorite DB) is no toy at all. PHP actually is running the internet far more than java has ever been. It would me a mistake to ignore scripting languages on the premises that MySQL does not support transactions/stored procedures / whatever. HINT 1: J2EE only has it place in big enterprises that are willing to get it becuase the big bucks it costs come with some big name company that offers support. Big enterproses still are unwilling to bet the house on 'get-it-from-newsgroups-on-google' tech support. HINT 2: the same big companies are very much likely to use Oracle, Sybase or DB2 for the DB back-end. But if they do, they already paid for the possibility to write all the business logic inside the DB, and have it running better and faster than in the applicatio-tier. HINT 3: even in enterprise contexts, the largest part of the majority of apps is pretty stupid form entry and validation. The presentation logic changes much faster than the data. And scripting languages are faster to write presentation logic than JAVA or dotNot. HINT 4: horizontal scaling is gonna be big. Real DB and PHP gurus know it can beat AS clustering anytime. OK, just my 2cents of flaming...