There is an end-of-2009 article by Floschi that shows the migration has overcome all the obstacles and made good progress:
- 2500 GNU/Linux clients spread over all 12 departments
- 20000 ODF templates produced and ODF is the standard format for documents
- FLOSS apps everywhere in use daily
It looks like most of the remaining work is grinding through installing GNU/Linux clients. Since everyone is now familiar with FLOSS apps, that should be fairly routine. It looks like 2010 will be a great year in Munich. The difficulty of the migration shows how great is the hold on IT due to monopoly. It shows that there is no time better than the present to escape monopoly.
The long-term benefits to Munich from this migration are obvious:
- low licence fees forever
- local control of everything
- freedom to innovate
- stable formats for documents
- open standards for documents
- low cost of maintenance because of thin clients and central management
- less trouble with malware/security
It is clear they made the right choice. They are on time and under budget despite the best efforts of monopoly to lock them in. The effort they made will be repaid manyfold by a much more reliable and robust IT system. Congratulations are in order.
LOL, Pogson! After some 7 years of relying on the Linux community to help them migrate their 14,000 Windows clients to Linux and FOSS software, they are almost 20% of the way! Only someone as numb as yourself could manage to see that as something to crow about.
The big job is not the installation of GNU/Linux on 14000 PCs but
I have converted systems and, with scripting, one person can do many in an hour. Last year, I worked out how to convert 24 machines in a couple of hours while preserving the ability of that other OS to boot. If the only consideration was converting the machines to boot GNU/Linux it would have taken less than one hour: setting BIOS to boot PXE and you are done. In Munich, likely each department had a few types of machines/roles that had to be integrated into the new system and smoothly with the least disruption. That takes much more time than the actual installation of bootloaders or thin clients.
No, all the difficult jobs are pretty well done in Munich. They have a standard client to distribute, the kind of stuff Extremadura did on a weekend but they have to preserve continuity and teach folks how to turn things on so I expect it could still be the end of 2010 before they are all done.
Give Munich a break. They had a long-established system that needed to be replaced one way or another. They took the most diplomatic, gradual, seriously studied to death approach and it worked. They have begun to enjoy the fruits of the effort having paid their last site-wide licensing fees to M$ and having setup an open document format. Even small conversions I have done take far more time to plan, purchase, transport than to actually install stuff. At Easterville, it took about 5 minutes to prep and test thin clients, 10 minutes to cart them around and install each one. Multiply that effort by 14000 and you have nearly a year of just moving equipment. Similar lengths of time were put into planning and designing the comprehensive system. Although voted up in 2004, they did not seriously get started until 2006. They are doing well considering they are minimizing disruption. For my work the disruption of a a few days is acceptable because of the immediate benefits. Munich’s plans were much more complicated than just installing GNU/Linux.
By my estimate Munich is 80% done the migration. They have all the end users up to speed with FLOSS and they are using ODF. The actual setting up equipment is trivial in comparison. Thank you for your kind words even if your numbers and ad hominem comments are irrelevant.
Amen. Migrations can be a bitch. Fresh hardware / OS install is the easy part. Migrating and PRESERVING thousands of documents is the mutant camel in the tent. Getting users to be comfortable with a different way of doing things can take a Nobel-class diplomatic effort.
I’ve seen articles pooh-poohing thin clients. But those articles leave out the headaches of poor document management. Various laws (Sarbanes-Oxley, HIPAA, Sunshine Law(s), etc.) REQUIRE that documents be preserved. And what if you are sued and have to go through e-discovery ? How about the White House e-mails ?
Another thing that can be troublesome in migration is keeping accounts. That other OS typically uses LDAP buried in AD. One can export most of the information readily, but not passwords/hashes, as far as I know. It is not a catastrophe changing everyone’s password, but it is a burden and things can go wrong.
The only things I have found weak in thin client technology is video, which is no surprise. 1024×768 refreshed is a few megabytes of network traffic and you cannot do it 30 times a second for video. For everything else, we point, click and gawk, so other can point and click while we gawk. My typical desktop user runs 200 kilobytes/s so, on a gigabit line dozens can be happy. One guy playing a video game can take 2 megabytes/s so a few will impact service. This is not a problem. Give thin clients to people who point, click and gawk. I think at least 80% of roles are suitable but not gamers or video folks. Folks who are seriously into animation and the like do use powerful workstations but for serious production/rendering, they use clusters of servers. Some people use gigabit per thin client but they still have to cut back the users per server to a smaller number. The point-click-gawk folks can be nearly 1000 on the hot multi-socket-multi-core servers choked with RAM but when you get to video you are best down to a dozen or so. On a fairly ordinary server, I have just let people do what they want and it works because the ones doing video are so few in number and if they slow things down, it is the video folks who notice, so they are self-limiting. I have done fairly outrageous things on running terminal servers with no one noticing, like installing software or transferring gigabyte files via NFS.
Your 80% estimate is way off. Assuming they can continue to convert 85 machines per month, the project will be completed in another 11.2 years, in the year 2020. Governments normally have to put people on the payroll to put a positive spin on lackluster progress. How much are they paying you?
Their old machines were old thick clients. They replaced them with thin clients using terminal services and newer thick clients. They installed FLOSS apps on the terminal servers. They trained the users how to use FLOSS apps. They converted ALL the documents and templates to use ODF. There is nothing left to do but replace the old machines. They have pilot machines in every department. All they have to do is clone their configurations. Their ultimate solution is thick client with fully automated installation and using all web apps. They still had half their budget unspent in June, 2009 but there isn’t much to do but replace client machines. They are doing that with a small crew department by department. That’s what’s taking time. The hard problems have been solved.
Criticizing their project without knowing the inner working is silly. They have their processes to follow. They made detailed public plans and made their choice publicly. About all I could disagree with them is that they are using thin client as an interim solution rather than the target. Perhaps that made sense a few years ago when they made their plans but I do not see the need to go to thick clients. They are less reliable and more costly for what they mostly do. It’s not difficult to convert FLOSS apps to run on a terminal server compared to producing web apps. The price of the hardware keeps dropping so going slowly makes a lot of sense for the budget. The performance of servers and networks keeps improving so there is no need to hesitate. The two motivations cross over somewhere. It’s not entertainment. It’s their system. Worry less about the process and more about the result. They have proven that they do not need M$ or at the very least, that they can use much less of M$ in their system. The file formats, the servers and the clients will all be open standards when they are done. Good for them.
The big job is not the installation of GNU/Linux on 14000 PCs but converting documents to ODF, converting templates to ODF, …
That’s a stretch at best. The OO framework allows one to tie into OO with (for example), Java which can be done within minutes, not years.
politicking/convincing every leader, elected official, manager, IT guy
That sounds exactly what cults do. It’s called brainwashing. If it has utility and saves money, then that’s the one main flaw in the freetard mentality isn’t it? To assume one’s time is worth nothing. A site license is dollars compared to the amounts they are spending and are going to be spending over the next few years.
converging 12 IT systems into some unified whole
Sounds like downsizing/rightsizing/outsourcing to me. That’s what corporations and government do when they are trying to save money.
By my estimate Munich is 80% done the migration.
Wow, so because you’re an armchair analyst this must be true and valid! After all, it’s on teh Internetz.
And by the way, get off the Pascal, that is soooo 1980s!
On your web site you claim that “most internet/games/systems programmers use C”? Internet programmers use C? Dude, are you serious? I’m afraid to inform you but there’s this thing called “the web” and it uses interpreted programming languages – not C. Whoa.
1) Certainly it takes only an hour or so per user to familiarize with OpenOffice.org well enough for routine use but these are government bureaucrats with forms to fill out. Many of them used macros that had no equivalent in OpenOffice.org and they had to be re-written/re-programmed, tested, and approved by some committee, not just of IT people but the end-users and their layers of bosses. I have worked in places that it takes two years to approve running a network cable through a wall….
2) Look, the bosses decreed by their own laws/regulations that the system needed review. Sticking with that other OS was an option considered and while, in the short term, it was feasible in the long term it was far more costly and with GNU/Linux the money stayed close to home instead of going to the USA. For politicians these are important factors. At the same time the lower levels of bureaucracy do not just jump when the politicians say to convert, so it takes information, demonstration, early adopters in every department, and lots of testing to convince everyone that it will work. A report on a shelf will not do it. Where I work, if there is an emergency that can be fixed by going to GNU/Linux, I can demonstrate the result and the end user is instantly satisfied and a conversion happens but if I want the whole school to change, it requires months of study, debate, demos, and there may be a few holdouts. That’s just the way society is. Leaders can lead, follow, or get out of the way. It works somehow. Even with all the politicking and blathering, they are under budget. The installation part has a cost that, for hardware, decreases with time so they may well end up under budget.
3)Any organization that evolves from a small office to 12 organizations is bound to have duplication of services. The city is not in the business of IT. They are supposed to keep the traffic flowing, and mundane stuff like that. If they can do it more centrally with GNU/Linux it’s better for them. Likely they would have had some element of centralization even with that other OS. It was overdue. Now they have a standard PC for everyone with software they can control centrally, cutting out a lot of unnecessary labour all over.
4)I have done migrations. Plugging in a PC is the tip of the iceberg. My biggest migration took months to sell the project, months to plan it in detail, and ten days to install and make work the entire system. It would have been much easier to buy the equipment and make it work, but I had to convince the decision-makers and their underlings and the end-users. The end-users were the easiest because they had never seen performance like they got from the new system. Just getting a meeting with the decision-makers took more than a month.
5) Certainly a lot of web sites use interpreted languages. I could be wrong about the numbers. Many schools crank out people who know PHP, for instance, well enough to make a website. Web sites with high volume rarely use an interpreted language, however, because it is too slow. Interpreting takes many times longer than executing compiled code. Interpreted languages are used because it aids rapid development. Most of the folks who write modules for Apache to run their website would use C to do that. I use Pascal and I usually use CGI scripts that are executed and not interpreted. It really speeds a site, especially if computation rather than database search is a big factor. Response time can drop to milliseconds instead of seconds for compute intensive web applications, like ballistics simulations. My last script involved a database and there was no advantage to using CGI because most of the time was spent on the database with multiple text searches. Optimizing the database query was more effective. For my CGI scripts, I use PASCAL because it is much easier to read and re-use the code than with C.
I did some quick benchmarks:
Kijiji (phpBB) 2.2s
Wikipedia (mediawiki) 3.6s
my scripts: 46 -1000 ms, depending on how much work has to be done
That is processing time on the site, not network lag. Now, one could argue that my time in writing an application is more expensive than a fraction of a second per click for my end-users, but I want to blow them away with the responsiveness of the system. Making local web applications snappy on the LAN is a big advantage when trying to replace local compiled apps on a PC with web applications on the LAN. Users would not be pleased with slower performance, for sure. Here, that other OS takes 15s to start a browser or word-processor and it takes 2s in GNU/Linux. Why would they not switch? Local web apps scripted in PHP take 2s typically when I can make it less than 1s by compiling.Static pages load in the blink of an eye. We wait seconds on the Internet here.
Quit throwing chairs, Steve. It is unbecoming a leader.
“Web sites with high volume rarely use an interpreted language, however, because it is too slow.
Interpreting takes many times longer than executing compiled code. Interpreted languages are used because it aids rapid development. Most of the folks who write modules for Apache to run their website would use C to do that.”
Ever heard of Facebook? They use PHP, not C. Also, NO ONE uses C for Web programming. You don’t know what you’re talking about, and rather than just admitting you made a mistake, you are going to sound more and more ridiculous.
“Web sites with high volume rarely use an interpreted language, however, because it is too slow.”
If you are going to stand behind this claim you may wish to post some references to statistics to back this up.
I would invite you to take a look on Monster.com (or Monster.ca) and have a look at all of the C programmers needed to do web programming. I counted none. Then look at PHP, C#, Java, Ruby, etc.
“Web sites with high volume rarely use an interpreted language, however, because it is too slow.”
You definitely need to do some catching up to current technology. Current virtual machine technology performs something known as just-in-time (JIT) compiling. The Java virtual machine has been doing this for several years now and in some operations, has reached C speeds.
“Most of the folks who write modules for Apache to run their website would use C to do that.”
Again, I would love to see some stats on this.
“I use Pascal and I usually use CGI scripts that are executed and not interpreted. It really speeds a site, especially if computation rather than database search is a big factor.”
CGI was popular in 1995 when web architectures were in their infancy. Quickly it was realized however that CGI was inefficient and non-scalable due to one process being assigned to each request. Now compare this to VM technology where threads offer the same service except when each thread is called, the system saves the time making the transition from user space to system space (which is required whenever processes are required to switch).
I would strongly suggest that you try some performance tests on CGI and compare that to some of the VMs out in play in current web technology.
My advice is to take a closer look at the world of technology around you before posting anything else. Your current posts are demonstrated a clear lack of understanding of the current day technology. Unless of course self destruction is your thing. In that case, retort away.
It looks like most of the remaining work is grinding through installing GNU/Linux clients.
Why is there any “grinding” at all? With all the money spent on this, haven’t they come up with a better deployment strategy than sending Florian Schiessl to 10,000 computers?
It looks like 2010 will be a great year in Munich.
Year of the LiMux desktop! TM!
The difficulty of the migration shows how great is the hold on IT due to monopoly.
Actually it shows the opposite. The “monopoly” is not erecting any meaningful barriers to the migration. From what I understand, they’re all still on Office 97 on NT4 Workstation. Yuck! The difficulties are due to dealing with the regressions by moving to inferior products.
It shows that there is no time better than the present to escape monopoly.
It shows this was an enormous waste of effort that could have been better spent on something else. Even if successful, Munich is now stuck in the operating system business in perpetuity. Their only choices are to continually absorb the ongoing development costs or compete directly in the general market in an attempt to spread costs. Is this something Munich really should be getting involved in?
low licence fees forever
Offset by several orders of magnitude by development, maintenance, and QA. If this weren’t true, software companies wouldn’t exist and everyone would write all software in-house.
local control of everything
freedom to innovate
Township entities are not known for their R&D prowess. Just look at this project. They can’t even deploy something that already exists let alone come up with something new.
stable formats for documents
open standards for documents
While you guys are busy battling yesterday’s battles, today’s Office formats are standardized and open. The source is right there: it’s just XML in a ZIP file. It’s only because OpenOffice sucks balls at rendering them that we hear so many complaints.
low cost of maintenance because of thin clients and central management
Thin clients??? This project is like the double whammy of false economy.
They are on time and under budget despite the best efforts of monopoly to lock them in.
Please describe these active measures that are being taken. You write as if there is genuine espionage/sabotage going on. If true, Microsoft would be guilty of various international laws, so this is a heavy claim.
By the way, since they can’t use Outlook, what are they using for their collaboration needs? Just email? Thunderbird? LOL, I’d rather use Gmail.
“I could be wrong about the numbers.”
You most certainly are.
Web sites with high volume rarely use an interpreted language,
Facebook? MySpace? Microsoft.com? Google? Yahoo? CNN.com?
Most of the folks who write modules for Apache to run their website would use C to do that.
Apparently somebody doesn’t know the difference between a server module and actual web programming? Are we suggesting that an Apache module is now a website? (Hint: the PHP and Perl modules are written in compiled languages, thet are however, used as interpreters).
I use Pascal and I usually use CGI scripts that are executed and not interpreted.
You know, people execute interpreted languages (Ruby, Python, PHP) via FastCGI these days, right?
It really speeds a site, especially if computation rather than database search is a big factor.
Right.
My last script involved a database and there was no advantage to using CGI because most of the time was spent on the database with multiple text searches.
You might want to look into using stored procedures for that.
Optimizing the database query was more effective.
You should ALWAYS optimize your database query, compiled languages won’t gain you so much as a milisecond if you’re, say, running a “SELECT *” when all you need is a handful of tables. And CGI? What is this, 1992?
At best, HotSpot compiles oft-accessed code on the fly, into Java Bytecode, but actually building websites out of compiled languages?
For my CGI scripts, I use PASCAL because it is much easier to read and re-use the code than with C.
So you went from trying to argue that most high volume websites (nice how you neglected to provide even a single example) use compiled languages instead of interpreted ones, to demonstrating that you don’t know the difference between a server module and a website, to meaningless benchmarks, to concluding that Pascal is easier for you than C.
And your last paragraph just begs for the question, why even bother writing web apps in that case, and not just replace the local apps with, local, native applications?
No wonder the migration is such bad shape, Whoever hired you should be fired and blackballed.
above should read “handful of columns”, not tables.
That’s about what I wrote. Others wrote that and it is nothing new. There are books on the subject so someone must be doing it. see http://oreilly.com/catalog/9781565925670
Google uses MapReduce (C++) and many sites use MySQL (C?) in their backends. If the work done in the back end is large enough there is little point in saving milliseconds using a compiled language, but systems that need fast response times do use compiled web applications.
cgi-bin finds 300 million hits on Google.
php finds 5.7 thousand million
Sure PHP and Perl etc are more used but for speed compiled code is faster. Without looking at the code it is hard to know what language a CGI script is in but some are not PHP or Perl.
MySQL != C
Pogson, these are not the 1990′s. NO ONE is using cgi. Web development is done with JavaScript, PHP, ASP.Net, or JSP.
I find it extremely difficult to believe you’re being serious.
and many sites use MySQL (C?)
So now we’re arguing that the database itself is web programming? All of those sites are using SQL (interpreted) to interact with the database, and some other interpreted language (PHP, Ruby, Python, JSP/Java, ASP/VB.NET) to manipulate the data fetched from the database, as well as (interpreted) client-side markup (HTML and JavaScript).
So, now, you’ve demonstrated that you don’t know the difference between a website and a relational database system.
And the link to the book you provided is expressly about writing Apache modules, again, because you can’t differentiate between a server module and an actual web site. Either that, or rather than acknowledging that you’ve got absolutely no idea what you’re talking about, you’re trying to shift the discussion away from your initial argument (which was that high traffic web sites use compiled languages (like C)) to “but the server applications themselves are written in C LOL”.
(though worth noting is that enterprise grade JEE application servers (including Apache’s own Tomcat, Jakarta and Catalina) are all written in pure (interpreted) Java, and Apache themselves offer an embeddable DBMS (Apache Derby) also written in pure (interpreted) Java.
cgi-bin finds 300 million hits on Google.
How many of them are current? And how many of those aren’t about FastCGI or getting various interpreters (Perl, Ruby, PHP, Python, etc) to run on non-Apache, FCGI-capable web servers?
CGI itself, as a means for actual web programming fell out of favour in the 1990s.
Find me even one website written in C. Just one, that’s all I’m asking for.
=====
“A CGI program can be written in any language that allows it to be executed on the system”
Mr. Pogson, thank you but I already know what CGI is. Also, that wasn’t the argument. The argument was the context switching incurred due to CGI – which requires a separate process to answer each request. What happens is that a context switch requires a request from user space, to go into system space, then back again. This constant switching back and forth requires a swapping of data in the registers. Even with hyperthreading, there is still a performance hit.
Virtual machines run (user) threads and so there is no context switch. Thus the virtual machines are more efficient at handling a continual increase in requests; thus we have scalability.
Because I’m a nice guy I will give you a free one which is: Fast CGI. Fast CGI (http://en.wikipedia.org/wiki/FastCGI) was an attempt to address this. However it is simply not used, nor was it ever as efficient as VM technology.
=====
“http://modules.apache.org/doc/Intro_API_Prog.html “Finally, in addition to providing incredible flexibilty, an API allows web engineers to develop applications under this API which previously required the slow CGI system.”
That’s about what I wrote. Others wrote that and it is nothing new. There are books on the subject so someone must be doing it. see http://oreilly.com/catalog/9781565925670”
Um, okay. Look Mr Pogson, the first link (at Apache) was stated written by by Sameer Parekh with an update by Randy Terbush, 6 June 1996. That’s almost 15 years ago. The O’Reilly link you provided is of a book written in 1999, 11 years ago. Frankly I’m surprised it’s still in print.
“Google uses MapReduce (C ) and many sites use MySQL (C?) in their backends.” MapReduce is a native library written in C but it has hooks in it for Java and other interpreted languages. With that, I’d say neither of us score a point for that one.
MySQL in C? Not sure what you are saying. I sure hope you’re saying that it’s written in C and not being accessed by “web C code”. If you’re suggesting the latter … whoa. That’s very much out of touch.
“cgi-bin finds 300 million hits on Google.”
Hits on Google is meaningless. Hits on a job bank offer a more meaningful representation of what is sought after by industry. Of course I’ll argue for your end (since you’re not showing much knowledge) and suggest that COBOL was getting huge hits in the job bank around 1999 – but quickly dissipated after the Y2K scare.
“Sure PHP and Perl etc are more used but for speed compiled code is faster.”
Have a read of these web pages Sir:
http://reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-performance.html
http://www.irrlicht3d.org/pivot/entry.php?id=446
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
And tell me if you still stand by the above statement. Some of the operations are within single digit percent.
When was the last time you checked, for example, Java, to C ? 1999? Things of changed Mr. Pogson, things have changed and greatly.
“Find me even one website written in C. Just one, that’s all I’m asking for”
That is an easy demand to make, but how does one prove what language generated the HTML in your browser? The popular PHP scripts brag somewhere but a one-off job may not.
PHP is interpreted by text passed from an Apache module. A module written in C can just as well interpret text. The advantage over a module is that it stays resident. This is not much of an advantage for a module written in a compiled language cached in RAM with all its data.
“PHP is interpreted by text passed from an Apache module”
What about Tomcat which is written in Java? The entire Web server is written in Java?
BTW, I see you’ve retreated to your happy place. Godspeed sir, Godspeed.
I’ve had to work with a C based educational portal before. So there are C websites out there. There were far more common in the 90s, when Java JSP or PHP didn’t exist yet.
Most high volume sites aren’t even dynamic. You think Wikipedia is written in PHP (it is), but the vast vast majority of page serves are static pages. The PHP interpreter is not called when you go to an article on Wikipedia. It uses a trick called caching to accomplish this.
As my own professional opinion is concerned, PHP is still the most popular web framework. Followed by Java, then ASP.NET. Although Django and Ruby on Rails are currently experiencing explosive growth. You shouldn’t have difficulty finding a job knowing any of these technologies well enough.
@Mr Windows: I see you keep changing the subject. That’s a standard tactic of trolls.
True. A really powerful site with lots of traffic will have everything in RAM. The caching of intermediates in the PHP/script interpretation does speed up PHP sites by almost a factor of five but still not as fast as compiled code. My point is that if one wants to get the highest performance, one should use compiled code. Others argue that programmers are more expensive than hardware so it is more economical to clone the servers to get more performance but they still max out less responsively. I have set up some sites that take 6s to generate a page with PHP, 2s with cached PHP and 0.5s with compiled code. Is it worth the effort? I Think so. If you already have hardware that does the same thing in 0.1s with PHP, then no. I am working with desktop users. They like the thing to respond quickly. They are so tired of waiting on the stuff they have waited on for years already. I find with PASCAL, I can generate code about as fast as PHP because I can compile and test modules separately. I do not have to build the whole thing. It may take me only 5s to change a routine and recompile and test. It’s a bit of my time a few hundred times for faster results millions of times later.
Are .. you .. serious? You think sites are programmed in C and not Java or .NET?
You fail at tech. Go back to your “job” at a school (which totally makes sense, seeing your archaic view of technology) and leave the web to the adults.
The performance hit of a context switch is almost nothing for modern equipment. Servers I built three years ago from dual core CPUs can do 64000 context switches per second while giving service that appears normal to a desktop user. That is why we use 64bit machines on services. They can juggle lots of processes. Even an old single-core machine can handle close to 1000 processes. If a CGI script is very small the cost of bringing it to life out of sleep in the RAM cache is very slight.
The reason I use web apps instead of local apps is because the servers have the resources to run out of cache and faster disc access so the performance for the end user is faster.
I run C, Java, PHP, Perl scripts all the time and PHP never comes close unless the bottleneck is the database/file system. It depends on whether number crunching or moving data is the task.
MySQL is written in C and usually demands some storage access. If storage access or the volume of C code executed in MySQL is more time consuming than the upper layers of the web application, it may be of no value to optimize the application at the upper levels.
btw, failpog, you’re taking quite a beating over at Linuxhaters. Welcome to the party, gramps.
Web apps, properly written can easily be faster than local, native applications on a PC. Today, I showed a user me opening a window in that other OS. It took forever. Doing the same thing in a web application with everything already cached and waiting for us was instantaneous. Doing the same thing with PHP may take seconds.
You can write an Apache web module to generate your HTML product. What do you think mod-PHP does? It’s faster than CGI because the module is resident and already linked to the server. I happen not to run power sites, so CGI is fast enough for me and it is faster than PHP when I use Pascal.
Here’s a simple demonstration:
Was that an illusion? Is it not due to the fact that the PHP process has to do more? Do you not think that that factor could be important when the fastest response time is needed?
Is it Hallowe’en? The trolls are out in force.
“Actually it shows the opposite. The “monopoly” is not erecting any meaningful barriers to the migration. From what I understand, they’re all still on Office 97 on NT4 Workstation. Yuck! The difficulties are due to dealing with the regressions by moving to inferior products.”
They switched to OpenOffice.org and ODF formats long ago. All that remains is to slip the OS out from under OO and they are mostly done.
“Offset by several orders of magnitude by development, maintenance, and QA. If this weren’t true, software companies wouldn’t exist and everyone would write all software in-house.”
They do not need to write OO, FF, or GNU/Linux in-house. That’s done. Their part was setting up the file formats, templates and the like. That’s the beauty of FLOSS. They do not need to do the whole thing in-house to replace what M$ and other vendors supplied. They only need to develop the tiny parts that affect their business, government.
Munich used thin clients as an intermediate step. I think their ultimate goal is GNU/Linux thick clients. It’s hard to tell with the language barrier… I think they could go almost entirely with thin clients. Education certainly can and a lot of government functions are of that clerical nature. Putting in data and taking it out does not require powerful local processors if the keyboard is king.
Do you need an essay on lock in? Number 1, NT was being killed so they were pressured to upgrade hardware and software to go the next step. The lock-in was the fear that their system would quit and they would have to pay now or later. Then their were the file formats, the arm-twisting by Ballmer, the smear campaigns, . The flak thrown at Munich was a thousand-fold more than what I get. Why did they deserve that? Was it not their own business to run their IT as they saw fit?
Gandhi said, “First they ignore us. Then they laugh at us. Then they fight us. Then we win.”
He was a wise man. If the haters have lost so badly and their “cause” looks so hopeless that they have to hammer on tired old men like me, GNU/Linux and FLOSS must be near winning.
I had some fun this weekend. Reports. On paper. I snatched them from an XP machine down the hall using smbmount, converted them to .pdf using unoconv, and printed them using Acrobat Reader on another XP machine (where a colour printer was). I can do whatever I need to do with my hardware with GNU/Linux freely and when XP screws up or slows too much, I can rewrite the hard drive and be in another world in a few minutes. All the staff have seen the magic and love it. We have our own little Munich on a much smaller scale and with a timescale of a few months or so instead of years, but the same things are happening. People are becoming free to use the full power of their IT instead of what M$ and the malware leave us.
XP had a narrow escape in the next room. Could not find a printer driver for a time. Checked the specs and substituted a driver for a similar printer. It worked or GNU/Linux would have been on the job. It may be later, anyway, because the teacher asked for childproof PCs. As soon as we get him some equipment, he will have a cluster for his students. In a few weeks I will have a new set of students exposed to the glory of FLOSS. We will have fun.
They do not need to write OO, FF, or GNU/Linux in-house. That’s done.
“Done?” Technology isn’t something where you get to a certain point and quit. Were that true, why are they bothering to migrate from their NT4 solution? It met their needs at one point, right? It’d probably take less effort to shoehorn Firefox and OpenOffice onto NT4, which they’ve already bought, then to expend all this effort into something that you make it sound will be promptly abandoned.
It’s incredibly naive to posit that once you slap on Firefox and OpenOffice onto some home-rolled distro that your needs are forever met. “Someone” needs to integrate fixes and changes, and, given Linux’s lack of standardized interfaces, this work needs to be delegated to distribution maintainers, who are more expensive than typical admins. How do we test and deploy system-level updates? That requires even more staff. What happens if Firefox or OpenOffice bites the dust? Aren’t they just as “locked in”? Do we expect Munich to absorb the maintenance efforts of these large projects?
That is an easy demand to make, but how does one prove what language generated the HTML in your browser? The popular PHP scripts brag somewhere but a one-off job may not.
And yet you can’t back up any of your claims with an actual example. that’s real cute.
PHP is interpreted by text passed from an Apache module. A module written in C can just as well interpret text.
The PHP module )mod_php) itself is written in C. I’m not sure what you’re getting at here, as the web programming/scripting itself is still interpreted by the PHP interpreter (which is written in C(. why is it so difficult to make the distinction between web programming and a server module?
The advantage over a module is that it stays resident. This is not much of an advantage for a module written in a compiled language cached in RAM with all its data.
The disadvantage is that it doesn’t scale.
I can do whatever I need to do with my hardware with GNU/Linux freely and when XP screws up or slows too much,
Yet you had to go through not one, but TWO XP machines to accomplish said example task, all the while using the newtwork printing capability built into XP on the first machine, would have accomplished the same task, in a fraction of the time, and saved you about 15 steps. Yeah, go Linux!.
If the haters have lost so badly and their “cause” looks so hopeless that they have to hammer on tired old men like me, GNU/Linux and FLOSS must be near winning.
So, what’s your schtick here, you make things up, get proven wrong over and over, play the gold card and declare victory? I supposed if we were to redefine ‘victory’ as ‘flailing’, you’d have most certainly accomplished it.
They do not need to do the whole thing in-house to replace what M$ and other vendors supplied. They only need to develop the tiny parts that affect their business, government.
Conversely that’s also the beauty of commercial software, you don’t have to develop it in house because someone else is there to do it for you, the benefit over foss (what’s with floss? even foss is a misnomer, as the fsf rejects the ‘os’ in ‘foss’), is liability. The vendor takes responsibility for their product – it has to work, or they lose your business.
Munich used thin clients as an intermediate step. I think their ultimate goal is GNU/Linux thick clients.
That’s absurd. Build a whole new infrastructure, then blow even more time and resources on rebuilding the infrastructure you just built?
It’s hard to tell with the language barrier… I think they could go almost entirely with thin clients.
So you suggest that any assumptions would be baseless due to the language ‘barrier’, then go on to make assumption, which by your own accord are entirely baseless.
Do you need an essay on lock in?
It appears that you do.
Number 1, NT was being killed so they were pressured to upgrade hardware and software to go the next step.
NT is nearly 20 years old, I figure the hardware is about as old. And so your answer to having to upgrade hardware and software is to change the software and hardware, that needed to be done one way or the other, brilliant. In 20 more years the new hardware will become obsolete as well, is that also lock-in?
The lock-in was the fear that their system would quit and they would have to pay now or later.
They payed up regardless.
Then their were the file formats, the arm-twisting by Ballmer, the smear campaigns
What arm twisting? And what format lock in? Word ’00 files are still supported in current versions of Office, and current versions of .doc work in older versions of Office via free plugins, and even at that, OO works on Windows just the same.
Why did they deserve that? Was it not their own business to run their IT as they saw fit?
As I recall, a lot of the flak was from citizens of Munich paying taxes to fund this waste of time and resources. It’s their right to complain about how public funds are spent. You’re Canadian ffs, we throw fits about this stuff all the bloody time.
@Mr Windows: I see you keep changing the subject. That’s a standard tactic of trolls.
Mr. Pot! Long time no see, I still you’re still hentbent on calling me black
Your friend,
Mr. Kettle.
Real cute, delete the comments that refute your nonsense. That’s mighty grown up of you <3.
“Most high volume sites aren’t even dynamic. You think Wikipedia is written in PHP (it is), but the vast vast majority of page serves are static pages.”
So that makes it not dynamic?
Dopey_Joe wrote “Are .. you .. serious? You think sites are programmed in C and not Java or .NET?”
Don’t put words in my mouth. Some sites are coded in C. Many are coded in a mix of PHP and HTML, but that costs more in response time. Is there any C programmer out there who would argue that C is not faster than an interpreted language? The development effort for C would be greater but only marginally and for some sites the benefits would balance that. The current rage in IT in the server room is to consolidate idle servers. Another way to reduce the number of servers is to code in a more efficient language so that each server can do more.
Using Google, I found some sites written in C:
“It’s incredibly naive to posit that once you slap on Firefox and OpenOffice onto some home-rolled distro that your needs are forever met.”
I am not naive. If you have a gigabyte of code in your system and OpenOffice.org, Mozilla.com, http://www.Debian.org and Kernel.org take care of 99.9% of it, your needs are mostly met. That’s what sharing in FLOSS is about. You contribute a small amount but get to use it all. With that other OS and Office, and InternetExploder, you get what they give you and pay for it again and again. The high profits of M$ prove that their product is over-priced. By sharing, we can have good IT for less.
“but TWO XP machines to accomplish said example task,”
HaHaHa! I did not need two XP machines to accomplish the task. One XP machine had the data needing processing and could not print to a networked colour printer. Another XP machine ( had a colour printer attached but not shared ) could not do the select all/print everything operation (no Office). I ran the data through a GNU/Linux box to convert 61 reports from .xls to .pdf which the second machine could print. This is an example of GNU/Linux adding value to XP machines, not depending on them. The operation took far less time than the printing operation. Sharing the printer would have taken about the same amount of time but there were firewall issues and security issues. Staff here can get GNU/Linux services via RDP from a GNU/Linux box. The GNU/Linux box can do many things that are not possible/legal with that other OS, like converting a bunch of files to PDF without adding some software. We do not need/want/afford throwing money at simple IT problems when GNU/Linux will do the job for free.
I do not recall deleting any comments in the past 24 hours. Spam is way down. Trolling is way up but I fed the trolls last night because I am kind. They tried to hijack the conversation to ignore/deride Munich but I enjoy all conversation about IT. Munich is doing well and non-interpreted coding of web applications still exists and serves its purpose. There is no requirement to use thick clients with that other OS and there is no requirement to use an interpreter for websites. Folks who believe interpreters are as fast as compiled code are delusional but for many purposes it is fast enough. Even CGI scales well enough if the CPU effort required is much greater than the overhead of setting up a CGI process. Linux can set up a process much faster than humans can respond to the process. I like CGI. It is simple and easy and works for me. It is faster for me and my clients.
KeepMovingTheGoalPosts(TM)
Pogson, you keep trying to make this a debate about interpreted speed vs compiled (I also suggest you consult current research about that, you may be surprised).
This is about the fact that you think Web programming is done in C. A tool itself being made in C does not mean that someone actually does the coding in C.
Going by your logic, you could write Java code, using Linux or windows, but EVERYTHING is written in C because the OS is written in C.
This syllogism seems to sum up your knowledge:
“C is a programming language. All programs are written in C”.
I ran the data through a GNU/Linux box to convert 61 reports from .xls to .pdf
So you’re suggesting that format conversion is a Linux thing? Dude, we’ve been doing that for over a decade by installing drivers for a non-existing postscript printer and printing to PDF: ctrl p and select virtual printer, done deal.
Acrobat/Distiller offer that sort of functionality. Ghostscript offers the same functionality, all provide the same functionality, but require a fraction of the requisite steps.
The GNU/Linux box can do many things that are not possible/legal with that other OS, like converting a bunch of files to PDF without adding some software.
Printer drivers: Free.
Acrobat: Free.
Ghostscript/viewer: Free (and GPL).
Staff here can get GNU/Linux services via RDP from a GNU/Linux box.
I certainly hope you’re not suggesting that’s something impossible/illegal on Windows. RDP is MS tech, and it’s built into all versions of Windows since at least XP.
Munich is doing well and non-interpreted coding of web applications still exists and serves its purpose
You’ve yet to show that you understand the difference between a web application and a server module.
I like CGI. It is simple and easy and works for me.
More power to you, if it works for you that’s fine, but trying to suggest that CGI (which has been largely deprecated in favour of FastCGI for about a decade, if not more) is efficient or scales well is just not based in reality. Context switches are expensive, no matter how you slice it, and there’s no way of going around it (other than eliminating the context-switches). It doesn’t scale, it has been proven not to scale, and that’s why it was replaced a long, long time ago.
People keep putting words in my mouth or taking them out of context. I have been around a long time and no about scaling. CGI scales better than PHP and not as well as FastCGI. I understand the bottlenecks in processes. My point is response time which has nothing to do with scalability. One guy clicks on a link and gets the result sooner. That will happen using CGI instead of PHP whether the system is busy or not if the work being done is in PHP.
Spock misses the point entirely that with our systems as configured the job of printing the reports would have taken an hour of clicking when I was working overtime all weekend preparing them. I did not want to spend the hour. By converting files I was able to get one of our systems to print the reports without obtaining any new software, at any price. I used what was available. Why the second-guessing? I know how to solve problems and I do it. I have been for forty years.
Adobe Acrobat is around $100. Prices are all over. What’s that about? I used OpenOffice to convert the files. It is free.
People keep putting words in my mouth or taking them out of context. I have been around a long time and no about scaling. CGI scales better than PHP and not as well as FastCGI.
PHP is run as FastCGI everywhere but Apache (and Apache’s modules don’t scale well (in terms of scaling upwards, that is, not outwards).
I understand the bottlenecks in processes. My point is response time which has nothing to do with scalability. One guy clicks on a link and gets the result sooner.
Originally, your argument was that people used it for all kinds of high traffic websites (those require scalability). For something accessed by one person at a time, sure, why not, as long as you can keep zombie process in check, don’t require future scalability, and don’t mind spending exponentially more time building something for the sake of squeezing a tenth of a second or so out of it.
That will happen using CGI instead of PHP whether the system is busy or not if the work being done is in PHP.
In 1995, sure, but once again, virtually every server except for Apache runs interpreters as FastCGI (with the exception of servlet containers, which can execute PHP via Caucho’s Quercus (a Java -> PHP bridge) which outperforms standard PHP by a 5 to 1 margin in most use cases).
Spock misses the point entirely that with our systems as configured the job of printing the reports would have taken an hour of clicking when I was working overtime all weekend preparing them
Then your systems aren’t optimally configured, and I mean that in the least rude way possible. Sharing the colour printer may take the same amount of time, this time, but next time, it’s a one-click process.
Setting up a virtual postscript printer (just install the driver for ANY PS printer that you don’t have) is also a one-click process, which saves you a considerable amount of time next time. Same for Ghostscript.
Adobe Acrobat is around $100.
Pro is around $100, the viewer is free.
What’s that about? I used OpenOffice to convert the files. It is free.
So is the acrobat viewer, so is ghostscript, so are the drivers for any random postscript printer – all of which eliminate the steps of having to pull the files from the first XP machine, to the Linux machine, and then sending them to the second XP machine.
The three time-saving options are all free, but you respond with (an unmentioned program) cost money, and you use OpenOffice (because it’s free). Just come out and say “But I’m an OO fanboy” and we’ll leave it at that.
unoconv -f pdf list of files
10 keystrokes, plus the effort of pulling the files from the first machine and sending them to the third, vs. ‘ctrl p’, return (print to to file on a network share), and print from the colour printer. Neither solution costs you anything, the later saves you time, what’s the problem?
Pogson, your original argument was that no one uses interpreted languages for high-traffic websites. I then pointed out that Facebook – which most would consider pretty high-traffic – uses PHP.
We do not want people all over the LAN printing on the colour printer. It is too expensive. We have students about. They like to print full-screen images of colourful people on colourful backgrounds. Sharing the printer also requires two firewalls to be reconfigured. Nope.
Acrobat Reader was not the problem. We had it on both PCs. It does not print .xls files. The printer with the colour printer does not have Office. We converted the files and moved them over the LAN. What’s so hard about that? Neither XP machine had a means of converting the files. M$ doesn’t like open standards.. Creating a virtual printer might be an option but this was less work and we have a standard image for these machines that would need to be repropagated as well. Much more work.
“colourful people”? Are they plaid? Polka dot?
We do not want people all over the LAN printing on the colour printer. It is too expensive.
You might want to look into Access Controls. It’s kind of like permissions on Linux, but more fine grained, you could easily allow only users from group x to access said printer (or if you’d prefer, even select users from said group) it’s all of maybe 15 seconds of checking and un-checking boxes.
About reconfiguring two firewalls to enable network printing, that’s an atrociously convoluted network setup, nevertheless, it’ll most likely save a lot more time in the long run, than setting it up takes, assuming that the printer is accessed regularly.
What’s so hard about that?
Nothing. I’m simply presenting a number of simpler, time-saving alternatives, there’s really no need to be so defensive about it.
Acrobat Reader was not the problem. We had it on both PCs. It does not print .xls files
XLS, that’s Excel, right? You know that Excel itself can export to a number of file formats, and though PDF isn’t one of them, several free plugins exist (though the virtual printer approach takes that out of the equation as well).
M$ doesn’t like open standards..
Since when is PDF an open standard? A standard, yes, but open? I suppose, by that standard, Tiff, Doc and Docx are all open standards as well, right?
Honestly though, what prevents you from exporting to XPS and printing that instead, then? If you’re using anything but the latest version of Office, you can still happily export to PDF, if you’re using the current version, you’re free to either use XPS, which amounts to the same thing, or use any one of the many free PDF export plugins available, either is simpler than shoehorning Linux into equation, seemingly for no reason other than for the sake of doing it.
Creating a virtual printer might be an option but this was less work
double-clicking an EXE and pressing return is too much work? There isn’t even the need to hunt down an appropriate driver, just use the driver for one of the printers that isn’t shared. You can even share the virtual printer on the LAN, thusly only requiring it to be installed once, on one machine.
It’s sort of comical that you’re willing to put in the extra effort into squeezing one tenth of a second out of a web app, but are dead set against something absolutely trivial that will save you a number of steps, in what you make out to be a regular process (presumably because it takes Linux out of the equation).
Whatever floats your boat.
I did not write that no one uses PHP. That is absurd.
Mr. That Other OS quoted me out of context above:
“On your web site you claim that “most internet/games/systems programmers use C”? ”
That’s not wrong at all. C is a very popular programming language for binary code. The Internet is more than web page generation. Tons of apps are written in C. I just prefer Pascal. It may well be that few sites are written in C but I wonder why. PHP is not in any way superior except that one does not need to compile/build. PHP is not faster than C for sure. It can be nearly as fast with lots of caching of interpreted intermediates but C still is faster. If PHP is a better language for rapid development, why is there not a PHP compiler that will generate binary code?… Well, what do we see here, http://www.phpcompiler.org , there is one. Must be a need, eh? So now we can have rapid development and rapid execution. Well, not that rapid… They claim 55% speedup. They could get 10-100X by using C directly.
Also “Now, however, Microsoft says it will make the feature available through a downloadable add-on.” That’s from the link you posted, you can still happily export to PDF, if you’re dead-set on using PDF.
I like PDF. It’s an open standard:
“ISO 32000-1:2008 specifies a digital form for representing electronic documents to enable users to exchange and view electronic documents independent of the environment in which they were created or the environment in which they are viewed or printed. It is intended for the developer of software that creates PDF files (conforming writers), software that reads existing PDF files and interprets their contents for display and interaction (conforming readers) and PDF products that read and/or write PDF files for a variety of other purposes (conforming products).”
and my typical GNU/Linux system has everything needed to produce and manipulate them. Why should I install some other software to do that?
“double-clicking an EXE and pressing return is too much work? There isn’t even the need to hunt down an appropriate driver, just use the driver for one of the printers that isn’t shared. You can even share the virtual printer on the LAN, thusly only requiring it to be installed once, on one machine.
”
You think I let users install apps? No way. We do not want teachers walking all over the place and printing at the other end of the building so we have lots of printers and do not need to share. Teachers who print a lot have their own.
Same thing about firewalls. When I came here XP machines were piled high riddled with malware. They had no firewall at all and the LAN was on the Internet. I put in a router with firewall and firewalls on all PCs and open nothing that is unnecessary. No malware infections since. Really, do you hecklers know anything about security?
We do not use AD. I have better uses for the server which was sitting idle on a shelf. It now runs Debian GNU/Linux very well and provides valuable file, database and web services. Don’t tell me how to run my shop.
“I did not write that no one uses PHP. That is absurd.”
Nice attempt to backpedal, but it won’t work. No one said that, what I did was repeat what you said, which IS THAT NO HIGH-TRAFFIC WEBSITE USES INTERPRETED LANGUAGES, BUT THAT THEY USE C INSTEAD.
Is it really that hard to admit when you’re mistaken?
Pogson, your original argument was that no one uses interpreted languages for high-traffic websites.
I did not write that no one uses PHP. That is absurd.
And Namelos never said that you did, though I do see why you’d try so hard to distance yourself from your original argument (it’s a bloody absurd claim, by any measure).
The Internet is more than web page generation.
The internet is all about web pages and content. As amusing as it was, at first, that you can’t tell the difference between a server, a web application, a relational database and a server module, it’s quite tired at this point. Keep digging that hole though, you’ll hit China soon.
Nobody disputes that compiled code is habitually faster than interpreted code (though in many use cases Java has shown to be as fast, and sometimes faster than comparable C code), we dispute your claim that _most_ high traffic web sites are written in C, rather than in an interpreted language, which not only false, but also patently absurd, (you then went on to shift the goalposts to the server modules, then to the server itself, then to the RDBMS), and of the examples you provided, not only is there any indication of any of them being written in C, not one of them is particularly high-traffic either, especially not relative to the likes of Facebook, Myspace, MS.com, CNN.com, etc which are all interpreted.
I like PDF. It’s an open standard:
Look up XPS, that’s an open standard as well, and beyond that, there are means to export to PDF even with Office2k7.
It seems that you’ve developed this “anything but microsoft” mentality and despite all of your vitriol over format lock-ins, the only one locking you into any format is well, you.
and my typical GNU/Linux system has everything needed to produce and manipulate them. Why should I install some other software to do that?
Of course, Linux fanboys don’t believe in productivity or convencience. 15 steps is ALWAYS better than 2, because 15 is BIGGER than 2.
You think I let users install apps?
I think you might need to get your eyes checked, gramps. The virtual printer only needs to be installed ONCE, on ONE machine, and made available via network sharing, thus providing everyone (whom you want to haver access) with access to quick file conversion capability.
The users aren’t installing anything.
Teachers who print a lot have their own.
And yet neither the computer used to generate reports, nor your Linux computer have access to that colour printer. But hey, who needs two-step conversion and printing, when there’s an excuse to trot out that Linux machine in all of it’s 14-extra-steps-for-no-reason glory, right?
I put in a router with firewall and firewalls on all PCs and open nothing that is unnecessary.
That’s a fairly standard setup, there’s absolutely no reason for it to take hours to allow something a trivial as a virtual network printer to be shared.
I have better uses for the server which was sitting idle on a shelf
I can only think of a few things more important on a sizeable deployment than central configuration management, pushing updates, centralized authentication and group policy mechanisms, but hey, no wonder you insists that even the most trivial task takes you hours upon hours to complete.
Don’t tell me how to run my shop.
Maybe the options are limited up in Nunavut (I certainly know how limited they were in Ikaluit, back when it was still called Frobisher Bay), but down here in civilization you wouldn’t be running anything, this is so far past sad, it’s not even amusing.
“They had no firewall at all and the LAN was on the Internet. I put in a router with firewall and firewalls on all PCs and open nothing that is unnecessary. No malware infections since. Really, do you hecklers know anything about security?”
These days Mr. Pogson, a rodent could be trained to set up the router/firewall to place the LAN behind the world of software hostiles; your ability to do so impresses us not.
“We do not want teachers walking all over the place and printing at the other end of the building so we have lots of printers and do not need to share.”
Walking is good. So too is setting up printer sharing – another feat a rodent could be trained to perform.
“Is there any C programmer out there who would argue that C is not faster than an interpreted language?”
No sir, but then again I don’t think anyone was arguing that this was in any way a truth.
“The development effort for C would be greater but only marginally and for some sites the benefits would balance that.”
Are you mad sir? I can write a web app using Java, Hibernate, Facelets, Richfaces, Seam, and some XML configuration files where the Java code takes up about 40 lines tops of code and have that web app offering AJAX enabled HTML to connect to the server and have Hibernate create my tables for me and populate them – and all before you could muster up a make file for your project, which by the way, would take you well over six weeks of full-time effort.
We’re not just talking a slight fraction of time difference here, we’re talking about several orders of magnitude of difference. We’re talking about you writing libraries for talking to the DB, you writing libraries for AJAX, you writing libraries for generating the HTML, CSS, Javascript – unless of course you wish to write hundreds of thousands of printf statements that have snippets of HTML, CSS, etc.
Really, and I do mean this honestly, please check out the current-day VM technology before uttering another retort.
Namenlos wrote:“Nice attempt to backpedal, but it won’t work. No one said that, what I did was repeat what you said, which IS THAT NO HIGH-TRAFFIC WEBSITE USES INTERPRETED LANGUAGES, BUT THAT THEY USE C INSTEAD.”
Not even close to a good attempt at revising my words. I wrote:
“most internet/games/systems programmers use C”. Which is true. Most programmers of any kind use C or some variant. PHP is a rather recent phenomenon and only a few programmers use it still because only a few programmers make web applications. Use of PHP is increasing rapidly but still very few applications are ported to the web. On my systems there are half a dozen web applications and several dozen binary applications.
I wrote:“Web sites with high volume rarely use an interpreted language, however, because it is too slow.”
Even websites that use PHP for the web-facing part will have lots of C code underneath. The database almost certainly and anything that is compute intensive. Asking for a password is not intensive use of a computer. Generating an image or simulating a trajectory is. Who wants to visit a website that takes a minute to respond? They might wait 10s for the good stuff.
WTS wrote:”I can only think of a few things more important on a sizeable deployment than central configuration management, pushing updates, centralized authentication and group policy mechanisms, but hey, no wonder you insists that even the most trivial task takes you hours upon hours to complete.”
I use Clonezilla for distributing images. I use GNU/Linux for centralized control. We will be going to GNU/Linux so there is no need to go backwards with XP/2003. We have a 2003 CD but it has never been used/implemented here. I put GNU/Linux on the server and it is giving amazing service. All that is required is the new budget to upgrade it with RAM and storage and nothing prevents it running the whole show. Don’t lecture me on managing a system. I have been there and done that many times. Central management is trivial with GNU/Linux. I can upgrade all/any systems without leaving my chair and I can freely share printers per-user/per-PC as needed. Here and now we have only a few colour printers and we choose not to share them. Reports are generated cooperatively and published by someone with a colour printer. Don’t presume your way of doing things suits us at all. I am here and know the resources available. Putting in the resources outsiders expect/demand would be silly.
Mr. Windows wrote:”Are you mad sir? I can write a web app using Java, Hibernate, Facelets, Richfaces, Seam, and some XML configuration files where the Java code takes up about 40 lines tops of code and have that web app offering AJAX enabled HTML to connect to the server and have Hibernate create my tables for me and populate them – and all before you could muster up a make file for your project, which by the way, would take you well over six weeks of full-time effort.”
That is why coding in C or other compiled language is only useful in critical situations. I can also accumulate libraries of code in Pascal to do the same thing. Code is re-usable. Thanks for the insight. I have been re-using code since the 1960s. Pascal has a very nice modular approach to separate compilation that does not require make for many projects. I have written a lot of code and never needed a makefile in Pascal. In 1984, I wrote a complete control system for a particle accelerator lab in six weeks from flowcharting to finished, tested, installed project. The code I replaced took six man-years to produce. Mine worked better. Our training time for operators dropped from six months to one month. I know the advantages of programming in high-level languages. I used Modula-2 which is descended from Pascal but with features helpful for hardware control and processes.
If you are so capable, why are you wasting your precious time arguing with me?
If you are so capable, why are you wasting your precious time arguing with me?
The beauty of RAD is that it leaves you with lots of time to kill. Personally, I don’t much care what language you use, and as I’ve said before, if Pascal makes you happy, more power to you. My gripe was the statement that most high-traffic websites use C for webprogramming, which is false, and the attempts to deflect attention from websites to server modules, to relational databases (friendly tip, if you want to further optimize database performance beyond optimizing the query, look into using stored procedures (I’m not sure if MySQL has implemented this in any useful manner (I don’t use MySQL myself, on the count that I don’t like to have to choose between full-text and performance vs. referential integrity), but it’s significantly faster as the query is pre-built and run by the database itself).
Beyond that, I merely offered easy solutions to improve workflow. I mean, honestly now, if it takes over an hour to reconfigure firewalls to allow sharing a single virtual printer, then there’s something that isn’t jiving regarding your configuration, but if it makes you feel better, virtual printers work on Linux, too, providing drivers are available – configuration isn’t as trivial though.
I can upgrade all/any systems without leaving my chair and I can freely share printers per-user/per-PC as needed.
But as you said yourself, it would take over an hour to configure your firewalls to allow it, which one is it – it’s either a trivial task or it isn’t. It can’t be both.
WTS wrote:”But as you said yourself, it would take over an hour to configure your firewalls to allow it, which one is it – it’s either a trivial task or it isn’t. It can’t be both.”
Yes, it can. With that other OS, I need firewalls everywhere. With GNU/Linux I would use the LAN for X traffic and fear no malware so CUPS would take care of everyone’s printing on the terminal servers. Centralized management is really centralized on a terminal server. If I have multiple terminal servers, openLDAP does the job of identifying them and CUPS still works even if the user is running on one server and the printer is installed/shared from the other. I can nominate a user as authorized to print in colour and it is done. It is quite common to have a networked printer beside a thin client or plugged into a thin client. I have used both AD and GNU/Linux terminal servers and GNU/Linux is much simpler for me and performance is better. Last year, I actually used AD to authenticate GNU/Linux boxes and it was a nightmare. Spaces in user names… Pauses (measured up to 30s) … Using openLDAP exclusively was very crisp and trouble-free.
“That is why coding in C or other compiled language is only useful in critical situations.”
I see we’re shifting the goal posts. At the beginning of this debate you claimed that “Web sites with high volume rarely use an interpreted language, however, because it is too slow.”
Before it was “high volume sites”, now it’s “critical situations”. Shifting the goal posts, a favorite debate tactic when losing.
“I can also accumulate libraries of code in Pascal to do the same thing.”
This would actually be interesting. Try and find the following libraries/frameworks for Pascal:
- An ORM framework (e.g. like Hibernate, NHiberate)
- A micro container (e.g. JBoss Seam, Google Guice, Pico Container)
- A templating framework (e.g. Facelets, or Microsoft’s Master Pages)
- A web component framework (e.g. Richfaces – a JSF implementation, or Microsoft’s server controls)
- AJAX framework (e.g. Dojo, Google Web Toolkit, etc.)
Update: I just did a search for web frameworks in Pascal because I was curious. I found nothing that supported any of these current web framework technologies that are so standard in Java, .NET, PHP, Ruby on Rails, etc.
I did come across a Pascal web project that appears to offer functionality that is about 10 years behind. Because of this, it might be just right for you in that it doesn’t take you too far ahead; that would be too much of a jolt. I suspect you are about 15 years behind and so taking it nice and slow and going say 5 years forward would be a nice easing into “the new technology”.
The project is called Nemesis Pascal and is found at: http://npascal.sourceforge.net/
This one is interesting in that they have PSPs: Pascal server pages. Also it’s GPL so you can rest peacefully knowing that you’re not feeding the evil beast: Microsoft. The name however is the sweetest part of the project; it is most appropriately named for this context. Do you know why Mr. Pogson? Because the Pascal server pages are … are you ready for this? …. They are INTERPRETED! Interpreted by the Pascal interpreter. Nemesis indeed! Muahahahahaha ….
I’m well aware of how directory services work, thank you (though I’ve yet to see a GPO-like implementation for OpenLDAP).
First, t’s a myth that Linux is immune to malware (I take it you didn’t catch wind of that Linux botnet that was discovered recently, or that Ubuntu screen saver debacle, etc, etc), there should always be a firewall, regardless of OS, as good practice. And really, a firewall is mostly a means to mitigating what malware can do once it’s on the system, and to prevent intrusion – you’d want AV to actually prevent malware, preferably one with on-access detection (see Avast! or AVG Free).
It’s actually quite simple to enable a network printer on a Windows network – share it on the host machine (this automatically allows the printer through the built-in firewall), and the rest of the machines on the LAN should be able to see it just fine – you’ve apparently already got LDAP services running, so setting up LDAP authentication should be trivial (I use AD or Sun’s OpenDS myself, depending on environment, and it’s a couple of seconds work on either).
Last year, I actually used AD to authenticate GNU/Linux boxes and it was a nightmare. Spaces in user names… Pauses (measured up to 30s) … Using openLDAP exclusively was very crisp and trouble-free.
I’ve generally had the opposite experience, but yes, it makes sense to auth linux boxes against openLDAP (which is quite comical if you consider that both AD and OLDAP are LDAP), Linux doesn’r mesh well well AD’s advanced features, and AD doesn’t mesh well with Linux’s Linuxisms, it is after all, intended to control Windows domains.
Personally I found the hassle of trying to get OpenLDAP and Samba4 (although at it’s core AD is LDAP, it’s much more than _only_ LDAP, which is why anyone who claims that they’re getting everything they’d get out of AD with OLDAP is full of a certain stinky brown substance) to act as a domain controller isn’t worth the effort by a long shot, not to mention the extra hassle of having two packages to maintain that are doing the job of one.
But then again, I don’t tend to have Linux boxes to worry about (the Sun servers and Macs play surprisingly well with the Windows domain controller). But like I’ve said, whatever floats your boat.
I have used Pascal Server Pages but it offers far too many features (bloat) for the CGI scripts I usually use. CGI has some overhead starting processes so the bloat is a negative. My CGI scripts parse a string and are done. You could call that interpretation but it is nothing about code and all about data. Applications need data.
It still remains to be shown how to determine what code generates the HTML for a website unless it is a common script or announces itself. Facebook and Wikipedia clearly use PHP largely but others say they use PHP only for the user interface. There is lots of C down there somewhere. To claim that C is not doing the work on high-volume sites is silly. I run MediaWiki which is similar to what Wikipedia uses and the database is the bulk of the work. Wikipedia.org can afford to have most of the database in RAM but for those who do not, the response time is largely taken up by I/O. GNU/Linux has the same behaviour. While BASH is an interpreter, the bulk of the work is done by other code built using C. There is lots of GUI stuff written in Python or Perl but they still may pass work to CDrecord or other application written in C. Interpretation is fine if the interpretation is short compared to the patience of the user.
Mr. That other OS wrote:
“I see we’re shifting the goal posts. At the beginning of this debate you claimed that “Web sites with high volume rarely use an interpreted language, however, because it is too slow.”
Before it was “high volume sites”, now it’s “critical situations”. Shifting the goal posts, a favorite debate tactic when losing.”
Some people have a richness of vocabulary that allows them to parse language containing synonyms. Others do not. Some know that every system may have a bottleneck limiting performance and eliminate it or accelerate it and others do not.
//Some people have a richness of vocabulary that allows them to parse language containing synonyms. Others do not. Some know that every system may have a bottleneck limiting performance and eliminate it or accelerate it and others do not.//
Some people can admit when they’re full of shit. Others cannot.
If you want to program web apps in C or Pascal that’s your choice. These people are lowlife trolls. Don’t waste too much time with them.
Robert:
I don’t believe that “high volume sites” can legitimately be parsed as a synonym for “critical situations.”
Is it possible that the richness of your vocabulary is blinding you to the poverty of your cognitive ability?
If you are making money or spending money on high volume, it’s critical.
`If you are making money or spending money on high volume, it’s critical.`
Nice. So if anyone is making money or spending money on high volume (whatever that means), it is therefore critical. Another shifting of goal posts. Now you can be right any time and every time.
They must be pretty desperate for teachers up there in bear country because … wow.
Teacher turnover tends to be high in the North. A lot of sissy city folk can’t hack it. Issues with teaching in the North include:
If you think you can hack it, apply: via EducationCanada.com.
While BASH is an interpreter, the bulk of the work is done by other code built using C
Egad, yes, we’ve been through this before, even the interpreter itself is written in C most of the time (obvious exception being Java, which is written using itself), in the case of a webapp, the server itself is often written in C (with the exception of j2ee), the DBMS is often written in C as well (with the exception of j2ee), the actual web programming, however in something like 99% of use cases is nopt being done in C, and is never done on high volume websites which was the original point of contention.
It can certainly be done (and more power to you for having the patience to do it with Pascal (I don’t find the tradeoff in effort/time worth the marginal perf boost mind you, though I get the best of both worlds with Java).
In fact, the closest thing to a high traffic website being done in compiled code is sites built with Java, since the VM compiles oft-accessed parts into bytecode, though it can be compiled, Java is nevertheless an interpreted language, mind you.
Of course, if you pretend that the server, it modules, database, the underlying operating system and the interpreter itself is the website (it isn’t), then sure, but then you’re grasping at straws while performing a monumental goalpost switch, but your inition assertion (regarding high volume websites) would still be wrong on the grounds that Java powers the huge majority of the enterprise (by many accounts, the very definition of ‘high volume’ and ‘mission critical’), and in a j2ee environment, the whole stack, down to the VM itself is written in Java (which is interpreted), but then I suppose you could argue that the underlying OS is written in C, ergo C is doing all the heavy lifting, even though it serves the sole purpose of running the VM.
Of course, never mind that the whole thing is a giant red herring aimed at an argument nobody actually made, which in and of itself is a poor (failed) attempt to blur the distinction between the actual point of contention (web sites) and something else (the underlying web server).
I am glad you agree with me.
Bash runs my system but it is used for command/control not production, most times, so it is not on the radar for CPU load. On a website using PHP in the same manner, that will also be true.
Trolls, indeed.
If they are at the stage where in any of these 12 municipal departments they can just haul in a thin client or switch a machine to PXE boot then they are not almost done. Essentially, they ARE DONE.
Yes. I know Windows can do Terminal Services. Ever dealt with the licensing nightmare that comes with it?
Have another CAL. Thanks, but no thanks.
Arguing that batch converting with a single command is less efficient than opening them one by one in Excel and printing them to a PDF virtual printer, really.. want to try to do that to a couple hundred files?
Around the turn of the century I was sysadmin for a company that grew from less then 10 to over 60 employees over a few years. Because of a tight budget that meant ending up with a mix of Windows 98, ME, 2000, and XP workstations. And of course flex workspaces with roaming profiles were a must.
BSOD galore whenever people moved from one workstation to another. Or moaning and groaning that it took so long to log in (because someone decided to keep a folder with a few hundred MP3′s on their DESKTOP). I can only imagine the same thing spread over fifteen thousand workstations. 1000 people to maintain 15000 workspaces. That’s one person for each measly fifteen machines. A capable sysadmin can easily manage a handful of servers and several hundred thin clients by him or herself. Back then I spent more time keeping inventory of Office/Windows/ProprietaryCrap licenses then actually getting any real work done.
So in Munich they will be able to unify all their workstations to whatever release of KDE they are happy with, without ever haveing to move from workstation to workstation or taking a single EUROpenny of taxpayers’ money for software upgrades. Never mind that fact that the all of Germany, and the entire WORLD might benefit from the work of Munich’s inhouse developers.
Give it another ten years and y’all might realize that proprietary “commercially unsupported” software is SO last century.
Excellent comment. Thanks.
Floschi has an update:”Quality over time in Munich”
“There is not just a technical switch from proprietary to open standards and free software, but also a general improvement and reorganization of Munich’s IT. A reorganization to centralized IT services for our linux client. Nowadays we’re doing much more than planned in 2003, to gain an efficient and sustainable IT structure, based on open standards and free software. That’s a long-term strategic objective, not just related to free software.”
I have enough trouble bringing one LAN segment into the 21st century. Imagine the work they have done for 12. They are in no hurry. They will just go to GNU/Linux in an organized fashion instead of “7″. It makes a lot of sense to me.