That Other OS On Servers Is A Pain In The Butt

While GNU/Linux is great on desktops, it’s amazing on servers. Faced with the burdens of that other OS and its needless complexity lock-in “Users attempting to migrate from Windows Server 2003 to Windows Server 2012 R2 are experiencing a rather difficult obstacle in their migration attempts. Microsoft has acknowledged a bug in which Kerberos authentication stops functioning in situations where Windows Server 2003 and Windows Server 2012 R2 domain controllers are serving the same domain, leaving administrators unable to log in.” businesses should consider the demise of “2003” as another opportunity to migrate to FLOSS, particularly GNU/Linux.

With GNU/Linux, you can run, examine, modify and distribute the software so you are never locked in the way M$ does. Often, migration to the next release is just a command away thanks to intelligent package management. You see, GNU/Linux operating systems are the sum of their parts. You can change one part or all at your convenience and it all keeps working. Breakage like users of that other OS experience every release just doesn’t happen because the OS is not out to get you but to provide you service.

In schools where I worked, most often we used XP alone or with “2003”. “2003” was no help at all. It made inexplicable pauses during authentication. It crashed when I logged in remotely. Sometimes I had to go to the server room just to reboot it. It had negative value compared to GNU/Linux. One place that used it for printing had the most unreliable printing I have ever seen. Compare that to my experience with GNU/Linux where I would install the stuff and it just kept humming forever. The logic of “we must run XP because that’s what everyone else runs”–>”we must run “2003” because XP won’t run well without it” escapes me. You don’t need M$ on desktop nor server.

See Clock ticking on Windows Server 2003 extended support timeline.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , . Bookmark the permalink.

64 Responses to That Other OS On Servers Is A Pain In The Butt

  1. oiaohm says:

    DrLoser I will give you the tools you can see for yourself how simple it really is. I can give you nice tar.gz of asp2php versions from 1999.

    The reality here is this is what you should have done before claiming it is impossible.

    DrLoser you have said that you are a web developer you should be able todo something as simple as run asp2php across a classic asp site. Even the old versions convert a huge percentage and include database interface change. Only thing asp2php does not deal with is a few link issues, complex sql queries, and all com objects(some it does by remapping them to other items inside php).

    DrLoser you lack the evidence that it cannot be done. So you are making base less claims. By me giving you all the tools and you doing it yourself you cannot claim I have rigged it in someway.

    Seeing the php will be simple to see if I have used any of my personal tools. To prove if I have or have not you will have to run asp2php yourself anyhow.

  2. DrLoser says:

    We’re drifting away from that gorgeous, cloudless day, some time in 1999, when oe either pulled off the impossible and moved a fifty person intranet application with dynamic web pages from WISA to LAMP in a single day, aren’t we?

    No matter. The explanation for that particular dramatic and incredible success can wait. As I’ve explained below, I’m fairly sure that there are three reasons for it.

    a) The entire site comprised static pages only.
    b) oe has Confirmation Bias and can’t remember quite how much effort it took. Which is fine. We all, every one of us, suffers from this effect. Particularly after fifteen years.
    c) oe just wasn’t up to much when it came to trivial WISA config, was he?

    No matter. Here, we have an oiaohm Challenge. The oiaohm Challenge to beat all oiaohm Challenges, in fact:

    DrLoser find me some 1999 asp code and I can give you the tools from the time period.
    No point spamming the reality here you are wrong. asp.net is to java. asp prior to asp.net is to php. So far you have not provided a suitable code base. Why should I waste my time trying to find some 1999 asp code base to kick you teeth in when if I do all you will say is I rigged it.

    So, what you are saying here, oiaohm, is that if I find you (as before, a simple two or three page “tutorial” style) a sample Classic ASP project — the sort of thing that you would indeed, and you are correct — have seen in 1999:

    You are promising here, on this site, in your immediately previous post, to use the tools of your choice to turn it into a PHP equivalent?

    That is a generous challenge indeed. You still seem unsure as to whether you mean the full LAMP stack, or just the PHP. (I will give you just the PHP.) And you are still failing to admit that your various “toolsets” were, in 1999, akin to bashing two rocks together and hoping for a spark. (I will give you any FOSS or other freely available 2014 tools of your choosing.)

    Your challenge to me, oiaohm, is that I provide you with a nice simple Classic ASP project upon which you can perform the voodoo that you do.

    I accept that challenge.

    Just one small thing. To make it worth my while, I expect you to promise that you will download your PHP — remember, I’m missing out all the awkward yet necessary stuff — to a publicly visible site of your choosing.

    Do you think you can promise that, oiaohm?

    If not, fine. You’d look like a total dag, but then I’d assume you’re used to looking like a total dag by now.

  3. oiaohm says:

    http://www.apache-asp.org/index.html
    This is perl apache::asp . Python calls their ASP classic style “Python Server Pages” this is part of mod_python.

    Notice a little trend here some classic asp pages run on Linux and Apache with zero modification. Activestate python and perl classic asp pages run with almost zero modification even in 1999. These are currently maintained versions of the old prior to ASP.net solutions. Sorry the site even back in 1999 did not have to be static to port quickly. What version beast of ASP was on the server in 1999. Microsoft or activestates. Of course I presumed worst case being Microsoft so requiring asp2php.

    Issue is psp or apache::asp is not going to behave like asp.net wrong internal structure and neither behave like Microsoft classic asp either because perl and python template systems are so different.

    JSP another asp classic relation but in design is also a asp.net relation.

    This is the problem Microsoft people only think there is such thing as MS ASP.

  4. oiaohm says:

    http://en.wikipedia.org/wiki/Active_Server_Pages
    I knew there was a better name. Classic ASP is 2001 and before its a vastly different beast to asp.net. Classic ASP and PHP have lots in common. Also the fact that Classic ASP was discontinued in year 2000 when you find any its migrate it.

    Reason why the Linux world never bothered with an environment to run classic asp is that it is quite simple to port to PHP. Script language to a Script language.

    Classic ASP could do quite a lot. Classic ASP was a competitor to PHP.

  5. oiaohm says:

    http://arshaw.com/phpti/

    DrLoser the version of “Redhat 4” mentioned in oe claim tells a date. 3 October 1996. It was not RHEL. Also the size cpu’s tell you its pre asp.net why July 2001 is 1 Ghz processors.
    brand new (then) screaming 600 MHz Dell workstation.
    oe claim is clearly before asp,net. Dell was not selling 600Mhz workstations in 2001 let alone 2002 when asp.net is first released.

    Yet you are asking me to replicate the same stunt with asp.net.

    You are not providing a valid test case matched to the time frame of the example. What you do on more modern is not the same as what you do on pre asp.net.

    DrLoser asp2php is not version 1.0 now. Version numbers are up to the developer to choose if it classed as stable.

    I will give you the impossible level of attempting to convert asp.net to php except in very rare conditions. oe point is not about modern asp.net. oe post contains more than enough information to age it.

    asp before asp.net has templates. php also has templates. They are compatible design. Templates in asp.net are incompatible design to php templates. Link here is php built in template system. Include files. asp prior to asp.net uses the same method.

    CSS version 1.0 is 1996. Asp prior to asp.net had embedded javascript. Not a issue. CSS 1.0 and javascript and templates. Yes this all works on that prior code using asp2php and you can download by using the source repository the exact versions of asp2php from 1999.

    DrLoser find me some 1999 asp code and I can give you the tools from the time period.

    No point spamming the reality here you are wrong. asp.net is to java. asp prior to asp.net is to php. So far you have not provided a suitable code base. Why should I waste my time trying to find some 1999 asp code base to kick you teeth in when if I do all you will say is I rigged it.

  6. DrLoser says:

    You’re not going to, are you, oiaohm?

    You pathetic little wimp.

  7. DrLoser says:

    Dr Loser why would I publish something I don’t class as quality work.

    It doesn’t seem to have stopped you, at any time over the last five years, publishing a mountain of gibberish in badly-broken English that nobody in their right minds would classify as “quality work,” does it, oiaohm?

    Go ahead, publish your PHP. The one nice thing I can say about PHP is that it is extraordinarily tolerant of mindless errors, be they syntactic or semantic. Thanks be to Postel!

    You fail miserably at the English language, oiaohm, but here’s your chance to redeem yourself in a more forgiving environment.

    Show, show us your PHP pasa doble!

  8. DrLoser says:

    But since we’re in fantasy land (as usual), oiaohm, and since you are now claiming that the important (and obviously visible to the end user on the intranet) bit is PHP and has nothing at all to do with the LAMP stack …

    … would you care to explain your proposed magic delivery system?

    No Apache. No MySQL. I guess it doesn’t really matter whether it’s Windows or Linux. (I pointed this out earlier in my suggestion of a WAMP stack.)

    Just PHP.

    Just PHP, nastily translated through a broken tool that was below version 1.0 at the time.

    Just PHP, with no JavaScript. No templates. No CSS.

    Nothing but PHP.

    Precisely what possible use might this cretinous proposal have been in 1999, oiaohm?

  9. DrLoser says:

    DrLoser it you who are pushing the idea that I have to port to LAMP.
    Pre 2002 ASP to PHP half a day or less is normal.
    This is a direct quote from me.

    Your “direct quote” is completely irrelevant, oiaohm. The original assertion was by oe, who I note has been suspiciously quiet in his own defence whilst you flail around with your farcical and completely unproven claims.

    Let me remind you of oe‘s original claim:

    I remember struggling to get a WISA intranet server working for a group of 50 folks … for about 3 full days and a brand new (then) screaming 600 MHz Dell workstation. After pissing away 3 solid days on this problem … Within a half day of mucking around in /etc, doing a little script foo, and working off the HOWTO’s (the key to old-school linux then) had a stable robust system doing better less than a 1/6th that hardware.

    My original observation was that this is impossible unless you are dealing with a very small number of totally static pages.

    My original observation was that, in that case, you would have to be fairly incompetent not to make a WISA stack (even in 1999) do the same thing, given three days.

    This now seems to have ballooned into some weird oiaohm willy-waggling that involves a grass-hopper approach to whatever Google site oiaohm last accessed (LAMP, asp2php, Java, whatever) …

    … but doesn’t actually lead to any proof that oiaohm can actually deliver. Which is not at all surprising. Because never once, in five or more years, has oiaohm delivered. You want to know why? Here, let me quote from the horse’s behind:

    DrLoser why would I publish something I don’t class as quality work.

    That’s the get-out of all get-outs, isn’t it, oiaohm?

    You’re the Marcel Proust of the LAMP stack, aren’t you?

    Shame, shame it is, that there are hundreds of thousands of LAMP stack professionals out there who just get on with the job, publish, and wallow in the acclaim of people like me …

    Who simply do not believe that you can do this at all.

    Let alone in the originally specified “half a day.”

  10. DrLoser says:

    Well, lets see, trolling a Linux-centric blog is not becoming of you is it? You are truly sorry lot, if this is all you have to enjoy your feeble life.

    Since I have vastly more things to enjoy, Dougie, I don’t think you need to worry on my account. Very sweet, though, after you exposed me for not having the PhD that I never claimed I had in the first place.

    Do you have anything other in your life than empty nominalist gestures? No? I thought not.

    Now, about this “I converted a dynamic WISA site to dynamic LAMP, I insist on PHP, there is no other way, why don’t you use this tool that barely existed in the first place, don’t forget to turn it into Java first, don’t worry about the SQL discrepancies, and certainly don’t bother yourself about the awkward fact that the templating system doesn’t work the same way at all” drivel …

    Well, you could listen to a fantasist like oiaohm, who has promised to prove me wrong by publishing his version of a tutorial ASP site.

    Or you could listen to a professional, like me. I’ve tried to do this sort of thing. I’ve actually spent months on a contract on a LAMP stack. I have no objection at all to building a web site this way.

    Or we could all sit back and bask in the glory of watching a small-town know-nothing under-educated snake-oil salesman throwing terms like “troll” around like pointless confetti.

    Depends what you want to learn out of reading a blog, I guess.

  11. dougman says:

    Well, lets see, trolling a Linux-centric blog is not becoming of you is it? You are truly sorry lot, if this is all you have to enjoy your feeble life.

  12. oiaohm says:

    http://xmlvm.org/clr2jvm/

    DrLoser it you who are pushing the idea that I have to port to LAMP.
    Pre 2002 ASP to PHP half a day or less is normal.
    This is a direct quote from me. Note I am very clear. Pre 2002 ASP to PHP. half a day or less is normal. Pre 2002 is pre asp.net stuff.

    So stop asking for stuff I said I don’t agree with. Half a day Migration of asp to php in 1999 is possible. asp prior to asp.net that you still find some businesses using that is possible to port in half a day to PHP.

    If the site is asp.net the target is LAMJ for asp.net 2.x and before. asp.net 3.x and latter normally mono asp.net.

    DrLoser why would I publish something I don’t class as quality work. A rapid migration does not produce clean tidy code. Half a day migrations have a price to pay. I said it was possible with luck to go from asp.net to php. I never once said that I would recommend it. In fact I have been very clear that asp.net and php, perl, python are in fact incompatible so any port could have major issues.

    Mainsoft grasshopper to Jsp/java in fact does not produce java source code. You don’t need java source code in a rapid port.

    DrLoser this is the problem you think I need source. Rapid migration is all about using short cuts. Some of the short cuts are monsters. Rapid migrated code may not be long term maintainable.

    But the advantage of a rapid port is that you can now replace section by section inside the same framework. Rapid ports are not always 100 percent successful or perfect.

    More complex sites based on more modern asp.net you would normally go to a mono/java hybrid. So you now can kill off the asp.net as over time site maintenance. Remember java can call and use mono aot produced .so files. .net on Linux becomes equal to JINI to java.

    This is my problem if you are porting an asp.net site to a Linux platform your target language is Java due to the many compatibility options.

    Any migration skilled web developer would know that asp.net conversion target is Java and nothing else unless you want insane amount of work. The means to mix existing .net code with new java code is what reduces the migration pain. Java can run inside .net environment and .net code can be plugged into a jvm environment.

    Selection of php, perl or python to migrate a asp.net site to is a sign of either web developer who does not know what they are doing or a web developer trying to make a huge pay day.

  13. DrLoser says:

    Not to mention that dougman, who is not even a man of any sense of the word, is a pain in the butt too.

    Aren’t we both so very clever, Dougie?

    May I just point out that childish nominalism does not become you?

  14. dougman says:

    I would also add that Dr. Loser, which is not even a Doctor of any sense of the word, is a pain in the butt too.

  15. DrLoser says:

    I’ll give you another five days for the Java to LAMP thing.

    I have no wish to make this difficult for you.

  16. DrLoser says:

    Incidentally, oiaohm, the original post from oe described, no doubt with a bleary-eyed backward look in time, a successful port of what we are currently presuming was a dynamic WISA site to a dynamic LAMP site.

    Foolish me, I was unaware that it is verboten to pollute a LAMP site with a framework that depends upon Perl or Python.

    LAMP Is PHP and forever more will be so.

    I suggest that, in order to complete your excellent demonstration, you therefore port the ASP thing to Java first, and then port it from Java to PHP.

    Otherwise, you haven’t really proven that oe had the necessary tools and/or experience to port a failed WISA dynamic intranet site to a successful LAMP dynamic site, have you?

    In 1999.

    In half a day.

  17. DrLoser says:

    I have said clearly and repeatedly todo asp.net quickly and stable I need LAMJ.

    Excellent, oiaohm. This is your idiocy for today. I thank you for making my job easier.

    As a matter of fact, and even assuming that anything you ever have said can be described as “clear,” you did not do that. Search down. You mentioned it once, on August 9th.

    But I am a generous soul and I am willing to grant you free use of that tool. Also asp2php, the virtues of which you have extolled on rather more repeated occasions.

    So then, where are we in this mythical chase for a half day conversion of dynamic WISA to LAMP? Let us listen to the Master:

    The mainsoft samples are vastly more of a challenge to jsp2php. “The Microsoft Personal Web Site Starter Kit” is a down right good workout and manages to screw up jsp2php in places.

    Well, sure. The first thing to bear in mind, when you are designing a web site, is to make sure that an incompetent lunatic can use inadequate tools to break it during some bizarre attempt to port it.

    Bwahahahaha!

    Little searching and filtering of for sql to sql and you are done.

    Good to hear, oiaohm. You’ve taken up my challenge. You have ported the original in something that I will accept is roughly half a day.

    I’ll even give you, say, three days to search, filter, and port the SQL.

    And then, if you please, publish the results so that I can be universally derided.

    Dropbox, SourceForge, whatever.

    Publish and be acclaimed!

  18. oiaohm says:

    http://dev.mainsoft.com/Default.aspx?tabid=174&tabname=Samples

    DrLoser sorry did you not read. 1999 asp is not asp.net. 1999 asp you can do to PHP in under half a day and be sure fairly sure of it. Asp.net its luck but still possible.

    I have said clearly and repeatedly todo asp.net quickly and stable I need LAMJ. Java has the required language 1 to 1 with .net. Now from LAMJ back to LAMP that is a problem.

    Even so that crappy example worked with https://code.google.com/p/jsp2php/ Total time DrLoser of the conversion and test 30 mins to get back to PHP. Mind you I class that as lucky. More complex sites from JSP/Java back to PHP don’t work. Asking for half a day does in fact give me quite a lot of working time.

    The mainsoft samples are vastly more of a challenge to jsp2php. “The Microsoft Personal Web Site Starter Kit” is a down right good workout and manages to screw up jsp2php in places.

    Nothing in your chosen example exceeds asp.net 2.0 DrLoser. You need something with asp.net 3.0 parts to make my life hard with grasshopper. It was kinda surprising considering the year of release being 2010 and asp.net 3.0 was 2006. I was in fact expecting it to fail.

    DrLoser the example you have given is asp.net not asp.

    The example you gave perfectly processes by grasshopper http://dev.mainsoft.com/Default.aspx?tabid=130 So producing a jsp/java site.

    Little searching and filtering of for sql to sql and you are done.

    If you don’t tie my hands with incompatible migration is fast. Migrating a asp.net site to Linux I do ask right to use java and mono.

    Some of the reason why I ask is https://code.google.com/p/nativelibs4java/ With Java/Mono combination you can build Hybrid so reducing your time to in production usage.

    Half a day migration does not mean clean either. You want half a day give your web developers access to all options. Java/Mono hybrid being one of them. The “WIS” bit is quick to remove. The ASP.net bit not so much at times. But for a half a day migration killing asp.net is not require just making it mono compatible(that most are out box). That example you picked also straight up runs on mono versions of asp.net.

    Half a day I can get a WISA (site where its asp.net) to a LAM? site. The ? is A for asp.net, J for Java . A for asp.net is basically 100 percent due to it minor work have success in half a day. Java is little bit more work particularity with ASP.net 3 and 4 stuff.

    Asp.net to PHP I will try if client requests but there will be no promise it will be if I am lucky.

  19. DrLoser wrote, “nobody in their right mind would claim to implement a seamless transfer between a dynamic WISA site with, say, a minimal three pages and a dynamic LAMP site in half a day.”

    Skilled web developers could probably do the coding easily in that time. They probably would want to spend more time on testing though before giving a guarantee because there are so many disfunctional browsers out there from M$.

  20. oiaohm says:

    DrLoser you are a fool in more ways than 1.

    The browser side javascript does not need to be changed if the server interface locations don’t have to be moved and the on wire response can stay identical. Nothing prevents a lam? system processing files ending in .asp or .aspx as java or php. So from the client side JavaScript nothing changed. So no you don’t need to deal with the javascript dependency very quick at all.

    http://freecode.com/projects/asp2php/releases?page=3
    You don’t know where to look. 1999 asp2php is 0.59 to 0.73. And those are mostly minor bug fixes.

    Asp2php anything it cannot process it spits out errors. Due to old asp and php being very close it is mostly a 1 to 1 conversion. So the output as good as code as the old asp was or fails very quickly.

    http://asp2php.naken.cc/docs.php Also even the 1999 version had replace all database connection bindings. Yes the differences in db bindings is handled or error-ed.

    Embedded resources is asp.net or latter. The original asp does not allow it. Tools for asp.net to java in fact handle embedded resources.

    Depend on the libraries(note asp2php would have error if it hit native code libraries) with old asp2jsp you would pay for this because if the libraries were written in visual basic it would convert them into java classes and if it hits a library it cannot process it errors as well. Quite a percentage of old asp sites would convert into php or jsp without work.

    SQL Syntax in 1999 was not hard to handle. http://www.swissql.com/products/sql-translator/sql-converter.html
    Yes swissql that is no more. So it was just have something run over the php/jsp and have it find all the sql calls and pass them threw swissql. If it throws a error you are in trouble maybe not a lot.

    SQL to SQL is not hard even today. http://dbconvert.com/convert-mssql-to-mysql-pro.php You just pay money to a different company. If you have paid the money for the automated tools you speed on conversion is fast.

    So in 1999 the first hour either your automated tools have either success-ed or failed. Majority of the half a day if it has worked is testing and waiting for the data from 1 database to copy to the other. Of course the old site remains active for most of this time. Downtime is 40 seconds if it has worked. If they have failed you are in for the long conversion process. If they have success-ed you have minor clean ups like fixing up client side javascript calls to .asp instead of jsp or php. Again this can be a nice simple find and replace macro.

    DrLoser to local and replace every use of a function in the Linux kernel takes mins because you use “Semantic patching” with a tool called Coccinelle.

    “Semantic patching” requires fairly much 1 to 1 rules on particular things. The good thing about databases is that sql language that all databases use has exactly the same response to buffer overflows. Its if you can process a 1 to 1 ish. MS SQL in SQL server is in fact less advanced than Mysql SQL for functions it provides. Data types can be a issue not a major one.

    Half a day is not zero cost. Rapid conversion requires paying money to have the right software and annoying this includes having a copy of Windows that you already have on the server you are migrating from.

    Template system used in old ASP and used in PHP are fairly close to the same. This is why its about how compatible the languages are.

    This is why asp.net to php you are in so much hell. asp.net and jsp/java have also a close enough template system to each other. Ok a few lines become triples but it still a 1 to 1 being 1 item from asp.net goes in and 1 item in jsp/java comes out. As soon as you cannot do 1 to 1 your language conversion becomes a problem.

    The largest Semantic patch to the Linux kernel replaced over 1 million lines. The patch was part of removing the big kernel lock. The Semantic patch was only 20 lines. 8,000,000 lines replacement using automatic tools todo it might not be very much code at all the programmer had to make. This is the problem having coder do the same thing over and over again brings errors. Having program automatically do it less errors.

  21. DrLoser says:

    By way of comparison, the Linux Kernel was, as of 2012, up to 15,000,000 lines of (mostly C) code.

    Two years on, let’s assume a bit of a clean-up and yet allow for significant extra features. I’m thinking 8,000,000 lines of code. Which is roughly 2^23.

    Take my imaginary doofus from 1991. (Not oiaohm. Exponentials don’t do much on zero lines of code.)

    Said imaginary doofus could knock out the entire Linux kernel in 1/(2^(30-23)) days, or roughly eleven minutes.

    Slightly implausible. But not nearly as implausible as oe’s original claim.

  22. DrLoser says:

    In the old days, a programmer could produce ~10 lines of correct code a day, properly debugged and tested. These days, machines/networks are faster so 1000 lines or more is doable.

    A very entertaining fantasy, Robert.

    In reality, neither the speed of the network nor the oomph of the CPU has even the remotest bearing on how many lines of code a programmer can knock out in a day.

    Let’s see: back in 1991 or so, I believe my best day was something like 400 lines of C. I claim no great distinction: it was mostly boilerplate file handling.

    By your logic, and applying Moore’s Law as a rough-and ready guideline:

    In 2014, that would equate to 400 ^ ((2014-1991)/1.5)*2.

    Which is quite a large number, I think you’ll agree.

    Even a doofus who could only knock out two lines of code in 1991 would now be able to knock out 2^30.

    Needz moar caffeine!

  23. DrLoser says:

    Pursuant to my new aim of exposing just a single, very stupid, part of an individual post by oiaohm, I will ignore the rest of his latest gibberish and reluctantly pick the stupidity most relevant to the current discussion.

    How about that there asp2php, then? Yay for foolproof automated tools!

    Shame it doesn’t really deal with JavaScript or library dependencies or embedded resources, isn’t it?

    Shame it has no knowledge of the radically different templating systems that underpin, respectively, dynamic WISA and dynamic LAMP sites, isn’t it?

    And shame it only reached version 0.76 (the earliest I can find) in 2004, isn’t it? That’s four years after the supposed “Miracle of oe.”

    And it won’t handle differences in SQL syntax. Or differences in db connection bindings. Or … the list goes on.

    Quite a lot to deal with in half a day, isn’t it? Even assuming that the tool — or indeed any automated language-to-language translation tool — is guaranteed to spit out 100% perfect code.

    Professional programmers do not do this, oiaohm. Even idiots like you do not do this.

    They just spend their time on other peoples’ web sites, making fatuous claims that, despite all the evidence to the contrary, they are for some reason convinced will not be exposed for the fraudulent nonsense they are.

  24. DrLoser says:

    It’s completely impossible for a WISA application to use PHP and/or MySQL already, Robert. The “A” stands for ASP.Net, which does not have PHP bindings, and the “S” stands for SQL Server. Nobody in their right mind would back SQL Server, a fully-fledged RDBMS which derives ultimately from Sybase, with MySQL, which isn’t even an RDBMS. (Add-ons like MyISAM or InnoDB notwithstanding.) Even the flavours of SQL are sufficiently different to make a half-day hack utterly impossible. And before anybody mentions MySQL’s transactional support, note that it didn’t even have this fundamental relational database support at the time oe describes (pre 4.0).

    Truly, the mind boggles.

    And no. There is no magic silver bullet to a “rapid application development” environment. No RAD on Earth, now, in the past, in the future, is ever going to make this absurd proposition remotely feasible.

    To be polite, Robert, I suggest that you try developing a sample “tutorial” two or three page dynamic LAMP website before you make assertions about how easy other people will find it. Alternatively, just for once, accept evidence from one of those “other people” who have done it for a living.

    It just cannot be done in half a day. And that’s just the PHP and MySQL bit. The translation between the different semantics of LAMP and WISA won’t make it any easier.

  25. DrLoser wrote, “Explain, please, how it is possible to migrate an Intranet application that does not depend entirely on static pages between “WISA” and “LAMP,” for your own choice of a value for “WISA” and “LAMP,” in half a day.”

    It’s hard work but it can be done. PHP etc. are rapid development languages, interpreted rather than compiled, so trial-and-error converges rapidly. One would likely create virtual environments, hack away, and get the job done. Of course, it depends on how large the application is. If it’s hundreds of thousands of lines of code, there’s no way, but if it’s hundreds or even a few thousand, it’s doable. In the old days, a programmer could produce ~10 lines of correct code a day, properly debugged and tested. These days, machines/networks are faster so 1000 lines or more is doable. It certainly is possible that an application on WISA uses PHP and/or MySQL already, making the job much easier.

  26. oiaohm says:

    DrLoser let be nit picky. You have not stated that the WISA site is using asp.net. So since you have not I will presume its not.
    asp2php conversion tool and a stack of sed or processor of your choice to locate and rewrite the database accesses(lot of database sql code is the same). Human work almost zero. So old dynamic page on WISA migrating in under half a day no trouble at all to pure LAMP. In fact if you have old ASP pages laying around you most likely should convert them.

    If you said WISA to Linux Envornment or to a LAM? where I have choice of interpreter. The migrations again are fairly straight forwards automated tools mixed in with a fix up scripts unless the program is using native code blocks that cannot be converted.

    ASP.net from Windows to Linux you need either jsp/java or asp.net on Linux todo them quickly.

    This is round peg square hole. ASP.net to python, perl or php is trying to push a round peg into a square hole. It is not going to work neatly. Enough force you can make it work but its not going to be a stable item.

    If you really want to force me to stick to pure LAMP where I am using PHP on the web-server there is a horible way. As you know asp.net can covert it code to C++ then you use C++ to C++ transformation tools. C++ to C++ convert asp.net site to a qml/qt site. Can be done quickly. Very quickly. Problem is you have opened up a Pandora’s box. You have just moved code that expects buffer overflow to be impossible to a language where buffer overflow is possible.

    DrLoser the reality I am just 1 tool short of been able to do it with your limited constants safely. If I disregard safe guards half a day is possible for a majority of sites on WISA to a LAMP stack. So in half a day you should have at least a working prototype if the conversion is possible without have to rewrite it without massive spend. Of course this is critical that you choose the right set of tools.

    If I obey safe guards you require access to languages that provide matching safe guards against the same type issues and buffer overflows. Languages on any platform that asp.net can be converted to that contain the same language level safe guards: JSP/Java. That is a down right short list. Anything else like python, perl, php, lua … will allow items asp.net forbids that the programmer writing the code could have put a try catch around to detect instead of detecting before error. Result of wrong language conversion is stack of bugs to chase down you would never had to.

    ASP prior to asp.net type safe guards line up with PHP so those sites auto converted to PHP work with minor effort.

    Level of effort of migration is linked to complexity of site(being like how much native code used and how many languages), Compatibility of target Language/s to source language/s(highly incompatible equals massive work).

    DrLoser don’t ask for the insane basically. Its insane to think you can migrate between incompatible designed languages without a lot of work caused by the bugs you will open up.

    DrLoser asp.net to php/perl or python is insane ammount of work on Windows let alone a were else.

    Skilled web developers are not stupid. If client asks them to do something like you have they say hey client think carefully this is going to cost a lot will you please give me X option. Why does skilled web developers not want to be tied up because they want to be able to service their SLA’s that pay them for doing very little.

  27. oiaohm says:

    Robert Pogson turnkey is a “Lamp Stack – Web Stack” The second half of the name allows stacks of extras. Not a infrastructure that is a pure. This is why it gets tricky. LAMP stack is only sure to contain the 4 core parts. Using any other parts like python or perl …. you have to check that those were added. This is the problem LAMP stack is only really referring to the 4 core being present. If you have something with extras it will have something extra in it name.

  28. DrLoser says:

    Let’s try one more time, shall we?

    Explain, please, how it is possible to migrate an Intranet application that does not depend entirely on static pages between “WISA” and “LAMP,” for your own choice of a value for “WISA” and “LAMP,” in half a day.

    It’s laughable even to suggest the possibility, isn’t it?

    Everything else is beside the point, LAMP “definitions” or otherwise.

    This claim that oe made in the first place is utterly risible, isn’t it?

    Feel free to go off on tangents. Just admit to yourselves that the original post makes oe sound either dishonest or else an abject incompetent moron.

    I’m sure FLOSS will survive, either way.

    And now … back to the tangents!

  29. oiaohm wrote, “Robert Pogson that debian instructions is not a per-assembled stack.
    A self assembled stack and obey any rules you like.”

    Someone assembles those “per-assembled” stacks. They can include anything they like. e.g. Turnkey Linux Lamp Stack, “LAMP stack is a popular open source web platform commonly used to run dynamic web sites and servers. It includes Linux, Apache, MySQL, and PHP/Python/Perl and is considered by many the platform of choice for development and deployment of high performance web applications which require a solid and reliable foundation…LAMP stack includes all the standard features in TurnKey Core, and on top of that:PHP, Python and Perl support for Apache2 and MySQL.”

  30. oiaohm says:

    Robert Pogson that debian instructions is not a per-assembled stack.

    A self assembled stack and obey any rules you like. Self assembled stacks are normally Lamp environments or Lamp software bundles.

    The instructions you pulled up on Debian are for installing a lamp server on Debian. So is the instructions for creating any kind.

    “Apache can be replaced by lighttpd!”
    Answer for official stacks is no. Applications designed for a stack are tested against that stack.

    The thing is a LAMP stack may have extras this is true. But if your application depends on them its wise to use one of the broader terms.

    Bitnami LAMP Stack that is basically bare min does not have python or perl. So this will get you into trouble. LAMP+perl or LAMP+python at least you end up with a system with what you need.

    Now lets say someone gets mean and optimises you virtual machine options for size. A LAMP(Linux, Apache, Mysql, PHP) comes in under 80 megs. Now you throw in perl and python you now have a 200+ meg image. You are seeing more and more of the bracket form instead of using stack as well due to the level of screw up that can happen if you just ask for LAMP.

  31. oiaohm wrote, “Download any of the LAMP provided stacks you will find no perl”.

    “# aptitude install perl libapache2-mod-perl2” see The “P” Part of Debian’s LaMp Wiki

    oiaohm wrote, “Stacks come as pre-configured infrastructure packages.”

    Stacks also can be built by piling one component upon another.

  32. oiaohm says:

    http://www.webopedia.com/quick_ref/webstack_acronyms.asp
    https://bitnami.com/stacks/infrastructure
    DrLoser you have not been in server space acquirements. Getting what LAMP name to use correct is critical.

    Stacks come as pre-configured infrastructure packages. Download any of the LAMP provided stacks you will find no perl. Its just not part of a base image stack. Worst may not be installable. If your application depends on the existence of perl you can kinda be in big trouble. Lot of windows people call Xampp Lamp by mistake.

    Only management in a Lamp stack image will be PHP related stuff.

    Explain, please, how it is possible to migrate an Intranet application that does not depend entirely on static pages between “WISA” and “LAMP,” for your own choice of a value for “WISA” and “LAMP,” in half a day.
    First you choose based on what the WISA is.
    If the WISA site is ASP.Net you will not be using a LAMP stack but will be using LAMJ stack or even possible a Mono based ASP.Net stack.
    If it old ASP not ASP.Net then you use LAMP.

    Now there are limitations to every single auto conversion tool. Not one has limitation only static pages. People telling people not to attempt migration make up the arguement you do.

    Half an hour running the automated tools over all the parts of a site will show up if like old asp pages are using ActiveX/COM that have to be migrated manually migrated. Or ASP.Net applications using native calls again manually migrated.

    DrLoser it does not matter if a site is big or small. What effects time of migration it what the applications on the site uses.

    Now a asp.net application using ADO designed to interface with many different databases and sticks to pure .net is going to be able to be moved without much work at all.

    Now if you have been asking the question of “WISA” to “LAMP” of course is impossible you have tied their hands into using php at worst at best php python and perl. Of course that is not suitable for ASP.Net pages most of the time. JSP/Java or Mono ASP.Net is what you require for a rapid migration of ASP.Net containing sites.

    DrLoser the problem is half a day Migration is not laughable. It can happen. This is why you give 1/2 hour to 1 hour assessment to to scan for what the site contains to rate its complexity. Yes size of site has no relationship to complexity.

    Like really hard would be a site bound to share-point features.

    Static pages claim is wrong. Like a business might be running at source what is php or python on wisa servers in asp.net. So the first half an hour might the what the hell with absolutely nothing to convert just stop stuff being converted.

    Each site is a unique problem. Some of those unique problems are insanely simple.

    Rule number 1 don’t tie the hands on what musted be used until after assessment.

    DrLoser if you want hard you would say migrate a site that depends on native platform Dependant code. That is more the problem than dynamic page generation. ASP.net dynamic page generation runs on Linux. If you are hosting outside your company you will be wanting java or php why hosting providers are happier to provide those than mono asp.net. Yes a Linux Apache Mysql Asp.net setups do exist.

    http://www.turnkeylinux.org/asp-net-apache
    Yes its a preconfigured stack option. So reality the only major things you have to deal with is the database stuff and anything mono.net or grasshopper cannot make work.

    DrLoser so its surprisingly easy if you don’t tie your web maintainers hands behind back.

  33. DrLoser says:

    The resident brain-dead nincompoop opines:

    That Exploit Guy reason why he does need to look it up when you are referencing the “LAMP stack” does not include python or perl.

    The resident brain-dead nincompoop is apparently, for pathetic reasons of his own, making a distinction between a “stack” and a “software bundle.” I presume a “stack” does not, therefore, include such things as Google Analytics or various management software, those being part of a “software bundle.”

    I presume that 100% of the people running servers on the Internet are devout adherents to the concept that it is vitally important to distinguish between “a stack” and “a software bundle.”

    Actually, no, oiaohm, I don’t. I was just pulling your leg. Go back to being pathetic about boustrophedonic text, please: that looked like a nadir you couldn’t possibly beat at the time, but obviously I underestimated you.

    Now, let’s start all over again, shall we? I, as a quondam web developer (I used both “stack” and “software bundle” — aren’t I the smart one?) have some small experience in this area.

    You, oiaohm, quite clearly have none whatsoever.

    But I could be wrong. I will give you the benefit of the doubt.

    Explain, please, how it is possible to migrate an Intranet application that does not depend entirely on static pages between “WISA” and “LAMP,” for your own choice of a value for “WISA” and “LAMP,” in half a day.

    It’s laughable even to suggest the possibility, isn’t it?

    Go on, oiaohm. Weasel away. Avoid details., Change the subject. Bring up irrelevancies.

    But you cannot change the blatantly obvious fact that anybody who can do this is literally worth millions of dollars a year in the real world.

    Why?

    Because that’s what major corporations will pay for people who can accomplish the impossible.

    They don’t pay much for weasel words, as you may have noticed from your own personal experience.

  34. oiaohm says:

    https://bitnami.com/stack/lamp
    That Exploit Guy reason why he does need to look it up when you are referencing the “LAMP stack” does not include python or perl. Never has. A LAMP software bundle can contain include Perl and Python. A LAMP environment can include openjdk as well.

    That Exploit Guy this is a case where 1 word makes a huge amount of difference. There were two correct choices.

    That Exploit Guy I should expect no difference you don’t know the finer points.

    By the way LAMP Architecture has the same meaning as LAMP Stack being only the 4 core components..

    The name I was referring to That Exploit Guy is two words “LAMP stack” It has a very strictly defined meaning.

  35. That Exploit Guy says:

    @ Dolding

    DrLoser please look up what a LAMP stack is. Perl is not included in the name.

    Back in 1999, it was not unusual to use CGI scripting with Perl instead of PHP to generate dynamic pages. What “LAMP” stands for is completely irrelevant in the given context.

  36. oiaohm says:

    http://www.diamondedge.com/products/Convert-ASP-to-JSP.html

    I just noticed ASP2JSP is still around. I just remember why I don’t use it you pay per 10000 lines. This is the thing rapid conversion comes with a price tag between some languages. Some conversions don’t exist.

    From ASP.Net to PHP by automated(Yes you really don’t want to do this). Grasshopper the asp.net to get JSP with Java. Then jsp2php. Problem here is double translation. About 1 in 200 will make it without being destroyed as the jsp2php is not that great. If it going to work you know in the first half an hour. With the amount of time it takes to recode a complete site half an hour on 1/200 chance is worth it.

    DrLoser has not used the automated tools to know what they can do.

  37. oiaohm says:

    DrLoser please look up what a LAMP stack is. Perl is not included in the name. The part extended LAMP stack that fits name include Perl and Python. If you just add perl you don’t know the define.

    Full extended LAMP define also include OpenJDK since LAMJ is classed the same. Its also when other http servers are used instead of apache it still can end up called a LAMP solution even that its not. Yes when someone asks for a LAMP solution you do need to get what define they are using out of them.

    1999 there was asp to php and asp to java.

    http://asp2php.naken.cc/ asp2php is still around for anyone who has any pre .net asp still around. Yes half a day conversions of ASP the stuff prior to ASP.Net was possible in 1999.

    Even then the conversion if the automated tools worked took less than half todo the conversion. The rule of half an hour to find out how bad the site is to convert starts 1997 with the first introduction of automated conversion tools.

    2002 is when ASP.Net comes into existence. You stated ASP.Net I was thinking you were referring to modern. Pre 2002 ASP to PHP half a day or less is normal.

  38. DrLoser says:

    To quote DeafSpy:

    You are clueless about DBs just as about anything else, aren’t you?

    This is entirely unfair. Oiaohm’s level of knowledge in anything (including his venture into Posix file renaming via Base64) has been proven to be as near zero as makes no appreciable difference.

    But oiaohm does know how to write backwards. Indeed, I accept his claim that he thinks that way, and that it makes anything he writes more intelligible.

    Obviously oiaohm refuses to write backwards, as a matter of course, because he’s not interested in whether or not we can understand his walls of gibberish.

    That is, after all, oiaohm’s unique, and sole, selling point.

  39. DrLoser says:

    Has anybody here actually been a web developer?

    I see no evidence. And you want to know the basis for my challenge? I have been a web developer.

    On M$ you say … obviously … but actually, no. On a LAMP stack. Most recently in 2008. CentOS, Apache, MySQL and Perl. The framework was Catalyst. (I do not recommend this framework.)

    The take-home for all you ignoramuses out there is that irrespective of the actual Web design (HTML, CSS, etc), you are not going to get more than two or three pages developed on any platform at all per day.

    And that’s on a good day.

    So, no, I’m sorry. Unless oe in 1999 was an incompetent without a plan who only had to deal with static page delivery, I don’t see any possible way that he could transfer an Intranet platform from one stack to another in half a day.

    That is prima facie absurd, and to be polite about this, I am convinced that oe has fallen foul of Confirmation Bias.

    It simply ain’t possible. And, if the man can do it, he’s worth millions.

    Why waste your time on a blog, any blog, when you can out-perform professional web developers by a factor of about 1000:1?

  40. DrLoser says:

    Yes, Robert. Thank you for confirming my amateurish assumptions about spitting out a DB schema in one form of SQL and inhaling it into another.

    We both agree: with sufficiently advanced tools (naturally, you are assuming that oe in 1999 had access to these sufficiently advanced tools, in 1999), it would take about half a day for a bog-standard recipe/intranet app.

    We can concur at this point, I think. Which is very good, because it is precisely the point I made in the first place. Many thanks for amplifying that point from your extensive personal experience.

    Without testing. Oh well.

    And also without translating one set of code+templates (ASP, general) into another set of code+templates (PHP or Perl, plus Template Toolkit or whatever).

    If you really, sincerely believe that anybody can do this in half a day, I suggest you disabuse yourself of that notion by trying to do it yourself. It’s an absurd proposition.

    Having said which, you could certainly improve your own site by updating the comment template(s) with either a div or a span wrapper. It would only take you half a day! Take the brave example of oe, all the way back in 1999, and just DO IT!

    No need to change any part of the stack at all!

  41. oiaohm says:

    Deaf Spy I did state that half a day was possible. But I did put limitations in.

    I did not say all would migrate without work effectively.

    Of course a half a day/quarter of day migration will not be optimised to be performing absolutely perfectly. Half an hour assessment can fairly much work out what kind of beast the site is.

    Deaf Spy of course you cannot read and I will not bother about the rest until you stop using stupid short hand.

  42. Deaf Spy says:

    Ohio, do you really expect to migrate automatically SPs from one db to another, and have them work efficiently?
    Never on this planet, unless we speak of CRUD SPs, which are pretty simple. Migration of BL SPs will fail spectacularly.
    You are clueless about DBs just as about anything else, aren’t you?

  43. oiaohm says:

    http://dev.mainsoft.com/Default.aspx?tabid=177
    Yawn. DrLoser talking about topics he should keep his big mouth shut on. ASP.NET site to Linux site the only work is fixing up the database stuff. You grasshopper it to java.

    There are automated tools for the Database and the ASP.net bits. The problem is they are not one integrated tool.

    http://www.mysql.com/products/workbench/migrate/ Of course the not all the automated tools are not freebies.

    MS SQL server tables to Mysql server tables approx 5 mins if you have your tools, Data in those tables how long does it take to copy. MS SQL stored procedures to Mysql stored procedures that might take a while so half a day migration you want zero of these needing work. The stored procedures can be dumped out and coveted ahead of the migration day.

    ASP.Net bit to Java that is another 5 min job for conversion about half a day testing if your testing is not automated. If the ASP.Net application was already compatible with the database migrating to.

    Half a day is possible. In fact quarter day is possible if code base of the ASP.Net application is good with automated testing suite. Requirements:
    1) No major volume of stored procedures in database or forms of stored procedures you can automatically convert.
    2) ASP.net already supports the target database or is simple to make support the target database because its quality code.
    3) you target language is Java or equal. PHP and perl by design are alien to .net.

    Majority of the 4 hours would be in fact testing. The code conversion and database conversion will be complete in the first hour if it going to be quick. If the migration has taken longer than a hour you have hit stuff like stored procedures or program uses highly fragmented access to database or it using some odd ball feature of asp.net that migration tool failed with.

    Of course a half a day/quarter of day migration will not be optimised to be performing absolutely perfectly. Half an hour assessment can fairly much work out what kind of beast the site is.

    Now if the conversion cannot be done in half a day now the conversion might take weeks of coding to prep.

    So its either easy or hell. There is no half way point.

  44. DrLoser wrote, ” I’m semi-fluent in both MySQL and SQL Server, and I don’t think I’m up to seamlessly switching 50 users’ worth of data between the two in only half a day. I don’t think anybody is, really,”

    Such migrations are fairly routine for experts. They have all kinds of tools to automate such things. Getting the applications to work with different databases is another matter. Usually one keeps a particular database with a particular application. Folks do replace applications eventually and the option to switch database arises then.

    My only opportunities to migrate databases have been few. Once, I ripped the database filled with useful stuff right out of an application that was only for that other OS. Strangely, the database was MySQL but the application had tons of C:\ stuff all over. That was imposed on schools for reporting data for schools and students. Another time the Canadian Firearms Registry was made available in sanitized form. It turned out to be PostgreSQL, no problem at all. I didn’t have to migrate any data. All I had to do was run the database on GNU/Linux. That was flawless.

    I know a guy who migrates databases at the drop of a hat for web applications. He’s fluent in 3 or 4 popular databases and finds the migrations rather boring. I gave him copies of some large databases of recipes and such which he migrated just for fun. Most of the relational databases spit out SQL, with variations, and migration of the data merely involves translating from one finite language to another, a mechanical task. Since he also writes applications for a living, he rarely has to migrate the applications. He just creates the database-specific parts and carries on. I once asked LXer to add a feature to their database of migrations to GNU/Linux and it took such a fellow just a few hours to add a couple of columns and adjust the user-interface and web-pages. Having some sort of standards for each kind of database doesn’t exactly make it easy but it’s almost always doable unless some weird feature of a database is used on one platform that is not available on another. I think good applications developers keep that in mind to avoid lock-in. I’ve seen a couple of web-applications that supported multiple databases. It was extra work and not really that useful since they used FLOSS databases which essentially eliminate lock-in.

  45. DrLoser says:

    WISA on a workstation compared to LAMP on a Pentium 90. In 1999, yet. How very instructive. (If only in the sense that oe didn’t do too much planning before he provisioned his intranet server.)

    First of all, the choice of OS has no bearing on this, does it? You could have gone straight to WAMP. (Apache v2.0, Perl 5.005 or PHP 3.x, yuck for either language version, MySQL 3.x.) You wouldn’t even have noticed that it was Windows underneath rather than Linux.

    And you’d have had ten times the grunt. Why not just pave over the 600MHz, incidentally? A bit of an odd decision.

    Secondly, the choice of database is almost certainly irrelevant. I’m semi-fluent in both MySQL and SQL Server, and I don’t think I’m up to seamlessly switching 50 users’ worth of data between the two in only half a day. I don’t think anybody is, really, but I congratulate oe if he reached drug-fuelled genius level on this one … even though he only managed plod-like bozo level on the original planning.

    So, no, it’s hard to believe that this intranet server originally did anything more complicated than serving up static pages. Which makes the choice of database irrelevant.

    But maybe those pages were dynamic, template based pages, involving just a few insertions like “name, address, favourite pet.” I can just about see that as a simple rewrite of SQL server tables into MySQL tables. In half a day..

    Not much time left for the ASP.Net -> Perl or PHP migration, is there? That’s a lot of fiddling around with templates, isn’t it?

    And a lot of testing, but then again as we all know nobody in the Free World bothers with anything as mundane as testing.

    So, then. Absent a few crucial details, this homely little tale of yore (which naturally is extrapolated from 1999 to 2014 with no adjustments) boils down to the following:

    1) Man provisions an intranet server on a machine with a limitation of 10 concurrent TCP/IP connections. (Not mentioned, but IMO the biggest complaint you could have against M$ at the time.
    2) Man does not realise that all he needs is a server for static pages. Consequently:
    2a) The choice of HTTP server is irrelevant here, although you could use the same one on either OS.
    2b) The choice of database is irrelevant here, although you could use MySQL on either OS.
    2c) The choice of page server (ASP or PHP or Perl) is irrelevant here, although you could use PHP or Perl on either OS.

    We’re not left with very much here, are we? Except the obvious inference that oe is either thoroughly incompetent, or telling porkies about the amount of time needed to port the intranet server from one platform to the other.

  46. oe says:

    I remember struggling to get a WISA intranet server working for a group of 50 folks whom were geographically separated for about 3 full days and a brand new (then) screaming 600 MHz Dell workstation. After pissing away 3 solid days on this problem I shoved that machine aside and pulled down an old Pentium 90 machine collecting dust on a shelf with a book on RedHat 4.0 with 2 CD-ROMs I had bought off the bargain table at my favorite used bookshop for about 5$ and gave LAMP a try in desperation. Within a half day of mucking around in /etc, doing a little script foo, and working off the HOWTO’s (the key to old-school linux then) had a stable robust system doing better less than a 1/6th that hardware. That thing ran like a Maytag server for the next 7-8 years with almost no touch maintenance, I can’t image WISA getting anywhere near that performance….a have more “touching the hot stove” and getting burned by M$ stories but this one was my foray into servery….That 600 MHz machine ending up getting paved over to Slackware to run machine tool controls…something I would never try with the MS stack (http://playingintheworldgame.files.wordpress.com/2013/05/windows-surgery.jpg anyone?).

    W=Windows
    I=IIS
    S=SQL (Microsoft SQL Server)
    A=ASP (or ASP .NET)

  47. luvr wrote, “Everybody seems to keep saying they “could care less,””

    Caring less or least is so horrible to contemplate, like death itself, I think it matters little if one could care less or not less when folks are in such an extreme.

  48. luvr says:

    Totally off-topic nitpick: Everybody seems to keep saying they “could care less,” when, what they really mean is that they “could not care less.”

    After all, if you “could care less,” then you must really be caring, mustn’t you?

    Mind you, this error is so common that it’s probably no longer worth complaining about, … but I guess that “I could care (a whole lot) less”; it’s just that I do care…

    Just saying…

  49. lpbbear wrote, “It wasn’t hardware. I wiped the old Windows Server and reloaded the system”.

    All through the ’90s, I believed the crock that hardware was causing that other OS to crash/freeze/crap out. How could I have been so wrong? I didn’t have a real OS with which to compare. As soon as I started overwriting that other OS with GNU/Linux, “hardware” magically behaved. I remember on my own PC in those days crossing my fingers every time I attempted to print or to save a file… I have been blessed many times to have shown teachers/students/principals GNU/Linux running side-by-side that other OS on identical hardware. That shocking experience paved the way for GNU/Linux wherever I went.

  50. dougman says:

    Windows, so aptly named, as window glass is VERY fragile.

    Billy sure hit the ball out of the park when he named it.

  51. lpbbear says:

    “Windows servers ARE a pain in the ass, I have dealt with a few of them. I still remember the brand new 2003 server that came from Dell and crashed within a day or so, I never even touched the blessed thing.”

    I just had to replace a Windows server recently. Its only job in the office where it was located was acting as a file server. That’s it, nothing too tough. Still it totally bombed one day and finally would not boot into the OS. So the office manager opted to replace the system with another Windows server on the assumption that hardware was to blame. That was the quickest solution in this case. I suspected otherwise and brought the system back to my office for testing. It wasn’t hardware. I wiped the old Windows Server and reloaded the system with a firewall version of Linux. It is now that same offices main firewall system and has been running flawlessly for a couple months.

  52. oiaohm says:

    By the way DrLoser RHEL 7 is only new its also unlikely that I would see it in active deployment. So the highest RHEL number you would be attempt to get to in active production is 6.x. This is the advantage of RHEL I buy a machine with at OEM provided license of RHEL I can downgrade it without question to something that is tested and proven in the RHEL line. Windows 2012 server lands that OEM you cannot downgrade that unless you have a volume license that goes over the top or old media laying around somewhere.

    DrLoser you did not get your question right at all. Even on your second attempt. 3 to 6 should have been the request. 3 to 6 with Redhat is simpler you don’t strike cases of legacy support features missing with Redhat product.

    Redhat products always lets you always choose the 12 months old version+. RHEL 7.x roll outs will start when RHEL 7.1+ is released. RHEL 7.0 is your production testing. All the .0 of RHEL releases has changed a lot and can cause you a lot of breakages if you are foolish enough to deploy them.

    Remember 2012 is R2. Problem here Microsoft has altered the feature mix between 2012 and 2008 release and R2 as well. Something Redhat never does. Feature mix alterations only happen in Redhat products when major version changes. So it clear from the version number that you may have some trouble.

    Some behaviors of Redhat we wish Microsoft would take up.
    1) bolt you features down when you do a Major version. Add features never remove them until the next Major version.
    2) Always include legacy network support features even if they are disabled by default until they fall out of usage.

  53. dougman says:

    Loser, your an idiot troll that brings up subject matter totally off tangent. We are busting on Win-dohs and could care less about upgrades from various iterations of Redhat.

    Windows servers ARE a pain in the ass, I have dealt with a few of them. I still remember the brand new 2003 server that came from Dell and crashed within a day or so, I never even touched the blessed thing.

    The entire OS had to re-installed with Dell support over the phone, after which all the layers of BS just kept getting the way of installing various customer related software.

    I ended up replacing it 3-years later with something far more stable and I am almost willing to bet, is still running and working today.

  54. oiaohm says:

    http://blogs.technet.com/b/askds/archive/2014/07/23/it-turns-out-that-weird-things-can-happen-when-you-mix-windows-server-2003-and-windows-server-2012-r2-domain-controllers.aspx
    This is a good write down on the problem. In fact its a on going nightmare.

    https://support.microsoft.com/kb/2768494 Is particularly good welcome to disaster. You turn AES off to support 2008 and 2012 result is now windows 7 clients non modified does not want to connect.

    Some people will say they have 2003 and 2012 coexisting this is only because AES is turned off. Why Samba legacy support you can have DES and AES kerberos accepting enabled on server.

    Fun of fun 2008 and samba back to Redhat 4 both can run DES and AES side by side no hot fix. 2008r2 you can still turn DES support back on making 2003 work. So 2008 has legacy support you hit this problem flick a switch and it goes away.

    The fact here is 2003 + 2012 in a network is not working. Either you have scripts going around manually resetting passwords so reboot machines or disabled server password rotation(security you are meant to rotate) or you have network encryption reduced to RC4(that is borken so ever new added system has to be patched) .

    Something to remember just because a system admin makes something work does not mean they should or that the are not working their tails off hiding the issues.

    Anyone claiming they have a working mixed network of 2003, 2008 and 2012 does not know what they are talking about. All the hot fixes to make the stuff work also come back and keep on causing issues.

    2003,2008 and Redhat 4-7 can work. Why all can KDC DES and the 2008 and Redhat 4-7 can KDC AES. Yes Redhat 4-7 can be in a network with 2012 no problems. Its only it is RHEL 3 that is lacking KDC AES like 2003 is. The fact RHEL 4-7 still can use KDC DES its not a major problem doing RHEL migrations.

    The reality if it takes years to migrate from RHEL 4 to 7 it does not really matter. 3->4 RHEL is required for 2012 entering network. To a person who has not done redhat migrations also would not understand why you would go in order. Seams like it would be more risky.

    The reality is each step if a third party application explodes you know what version it died at so what chroot it has to be contained in to work. 3->7 in one jump and some third party program you need now no longer works what runtime does that application truly need.

    It is also very strange for a RHEL 3 to still be around. Why RHEL3 ->Centos 4 or Scientific Linux 4 upgrade over it have been possible yes a Centos 6 -> RHEL 7 is possible. There is very little reason to be more than a version or 2 behind on a redhat/redhat relegation solution.

    The Redhat relations are that close you use the same instructions to upgrade. Migrations of Redhat systems are normally spread out over years. Redhat subscriptions always cover the most current versions. Redhat 3 was end of life at the start of this year. Redhat 4 is end of life next year.

  55. oiaohm says:

    DrLoser really you should never be let near servers. You don’t get your versions right. You think a migration plan saves you. So you would design plans that cost too much money.

    Really this is a real example of an install. The install is spread over 20 building VPN linked spread across a complete state. There is at least 1 Windows 2003 or 2008 boxes at each location. Now write a migration plan to Windows 2012 with only 1 visit to each location and don’t cause any lock-ups. You will find no option bar to visit locations twice. Why you have to nuke the 2003 before the first 2012 can be deployed. Then remember you can have N+1 servers at some locations. What is a +1 server is powered off.

    Same example Redhat is straight forwards. Install the new version of Redhat 7 with legacy modes enabled so able to talk to Redhat 3 systems perfectly. Remote turn off legacy modes when you have removed all Redhat 3 age systems. Number of on site visits requires is 1 and 1 remote management task after the site visits and you are done.

    Reduced site visits equals reduced cost of Migration.

    DrLoser I understand TCO on a Migration Path. Linux has lighter TCO on Migrations due to legacy support options.

    DrLoser by the way you have not worked with bulls. To a 1 million dollar bull most fences and gates is a suggestion.

    More exact example would be you have a 1 million dollar bull with many gates in and out of the paddock. Due to age and lack of maintenance a few gates have fall off from the bull rubbing on them and don’t enough resources to replace them all straight away on hand. So as a temp measure Linux farmer replace them with a bit of tie wire until replacement is ready even leaves the wire there for a bit after the gate is replaced(as a marker on what gates are new)

    Problem if you are Microsoft farmer you don’t have tie wire and has to replace the complete gates so the Microsoft farmer lose the bull because they cannot replace the gates fast enough.

    Linux farmer avoided the problem by legacy option of a bit of wire cross the gateway instead of a gate.

    Its a Microsoft conference example about closing gate as so not to loss bull. Its always fun to throw in what happens if gate has failed worse you have a field where many gates has failed at once and you cannot leave the bull alone to get a new gate until the bull is contained. This is vastly closer to an enterprise network. The bull is the operations that have to keep on running.

  56. oiaohm says:

    DrLoser its one thing to have a migration path. Redhat and Microsoft has a Migration path. Redhat has legacy support on network protocols. In a large network updating everything at the same time is hard. Particularly with Microsoft idea of ADS trees that spread across buildings. So you install a windows 2012 server somewhere in a business and the 2003 starts playing up.

    Big complex networks is really simple to make a migration mistake. Large network 2003 to 2008 is quite decent.

    OEM versions of windows 2012 server don’t have downgrade option. DrLoser there is a worst land mine. There are a few NAS boxes with Windows Embedded Server R2 2012.

    Large enterprise will not be migrating a solo server at a solo location. So they will have a mix of 2003 and 2008 before migrating to 2012. Some of those 2003 issues could be NAS. Either old Linux NAS or old Windows NAS.

    DrLoser migration path is all well and good. Legacy support is critical to performing a migration without have issues in large enterprise.

  57. DrLoser says:

    If you do a windows 2003 to 2008 then to 2012 R2 you still end up with a disaster because you cannot switch 2012R2 systems back until the 2003 are done.

    Let me explain the concept of a “migration path” to you, oiaohm.

    No, wait, that would be a waste of time.

    Let me explain the concept of closing the gate to a field with a $1 million prize bull in the field.

    At least that would save your unfortunate employers the insurance for a $1 million prize bull.

    I could probably save them even more money by sending them a brief email stating: Do not ever, under any circumstances, let this man-child near a computer of any description. Particularly not a server, no matter what the OS.

    But then again, I’m guessing they’ve already figured this one out for themselves.

    Have fun with the electric fence maintenance business!

  58. lpbbear says:

    “Good catch, ipbbear. Very good catch!
    I’m impressed.”

    Its lpbbear (L) Apparently you can’t distinguish between a l and an i in Winblows even with all of its highfalutin true type whatcha ma jiggers .

    “Not only can you count up to seven without taking your shoes and socks off, but you can also be tremendously pernickety and totally miss the obvious point at the same time!”

    You had a “point”!!!!!????

    I thought you were just exaggerating like all trolls do and you figured no one would notice your fubar. (or you just didn’t know in the first place)

  59. oiaohm says:

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Installation_Guide_x8664/s1-upgd-migrate.html
    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch-upgrade-x86.html
    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-upgrade-x86.html
    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/chap-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Upgrade_Tools.html
    That is the instructions from RHEL 3 to 7.
    DrLoser
    Allow me to rephrase my question. When was the last time that Robert migrated a large, enterprise, RHEL 4.0 server to RHEL 7.0?
    The answer is because they don’t have to not at least directly. When you have a RHEL 7.0 license it covers all the prior versions. So the process for updating a RHEL 3.0 to RHEL 7,0 is. RHEL 3.0 migrate to RHEL 4.0, RHEL 4.0 migrate to RHEL 5.0 then RHEL 5.0 to RHEL 6.0 then final RHEL 7.0. You don’t have todo a big jump.

    DrLoser why are you asking Robert a RHEL question when he is a Debian user. Debian is a enterprise server OS with many companies selling enterprise grade support.

    Also RHEL 7.0 has the options to use the encryption samba on RHEL 3.0 uses. Not that you should but this makes migration nicer until you have nuked the RHEL 3.0 systems. Yes you can flick up to newer encryption once you are at RHEL 4.0 and newer everywhere. Why RHEL 4.0 has current release samba as a option http://ftp.sernet.de/pub/samba/3.6/rhel/4/ so do many other distrobutions that age including old debian.
    Etch from debian is still getting new versions of samba. Yes the 2007 release. rhel 4 and centos 4 that is 2005 release. When networking with linux enterprise distrobutions inside 7 years of current date and your distribution first release date you will be will be able to talk all current compatible protocols on network. RHEL is 10 years. 2003 is a little too far. If you distribution release date is inside 15 years of current date newer Linux distributions will have the means to be told to run older protocols to be compatible. Really you don’t want to be running a 7+ year Linux distribution just brings headaches.

    You need to say RHEL 3.0 DrLoser to be suffering from the microsoft networking encryption failure issues forcing upgrade of a RHEL or building from source. Also RHEL 3.0 is the same year of release as Windows 2003. You were giving a link to redhat versions and you could not even line your question up correctly. You had two errors the starting version and the ending version.

    Also if you are on RHEL 3.0 and you are in trouble there is the no pay solution of upgrade to centos or other redhat clones.

    If you do a windows 2003 to 2008 then to 2012 R2 you still end up with a disaster because you cannot switch 2012R2 systems back until the 2003 are done.

    DrLoser like it or not this is one area where Linux is nicer.

  60. DrLoser says:

    Good catch, ipbbear. Very good catch!
    I’m impressed.

    Not only can you count up to seven without taking your shoes and socks off, but you can also be tremendously pernickety and totally miss the obvious point at the same time!

    Well done, well done indeed!

    Allow me to rephrase my question. When was the last time that Robert migrated a large, enterprise, RHEL 4.0 server to RHEL 7.0?

    In the best traditions of computer science, you will note that all the other details are orthogonal and unchanged.

  61. lpbbear says:

    “Have you tried to migrate a large, enterprise, RedHat server from 4.0 to say 13.0, Robert?”

    I don’t think anyone has unless they have a time machine…..

    https://access.redhat.com/articles/3078

  62. DrLoser says:

    Have you tried to migrate a large, enterprise, RedHat server from 4.0 to say 13.0, Robert?

    No? Thought not.

  63. oiaohm says:

    Making XP and Windows7/8.1 play well even on a Linux server is hard can be downright impossible on a Windows server. Issue is both have different versions of group policies where they overlap they fight.

    https://bugzilla.samba.org/show_bug.cgi?id=7901
    This same encryption issue turned up In Samba as well with 2008. Samba can still be ordered to process old encryption not that you should.

    If you must run XP and 7/8.1 run samba and use folder based on OS for storing group policy. So XP only sees group policy for XP and 7/8.1 only sees group policy for it.

Leave a Reply