Microsoft loves Linux so much its R Open install script rm'd /bin/sh Microsoft had to emit a hasty update for its R Open analysis tool after developers found the open-source package was not playing nice with some Linux systems. The issue was brought to light earlier this week by developer Norbert Preining, who found that the Debian GNU/Linux version of Open R – Microsoft's open-source …
Bah, just Windows developers diverted to Linux work, without sufficient competence building.
Remember the saying, "never attribute to malice that which can be adequately explained by stupidity".
But even so,
rm /bin/sh
ln -s /bin/bash /bin/sh
in an install script is a pretty monumental display of stupidity, unless your script is meant to install Bash itself.
The other thing that jumps out is that /bin/sh wasn't even replaced atomically.
/bin/sh did not exist for a moment, and every other thing running on the system relying on it would have gone boom.
I thought R was statistical, and statistics was insidiously difficult. Based on the assumptions displayed in the wrapper, I'm not sure I'd trust the package either..
this used to happen with Windows back in the day, when they'd just change your AUTOEXEC.BAT and CONFIG.SYS files, assuming they could.
It's the *kind* of thinking that Micro-shaft is INFAMOUS for.
(not to mention forced updates and Win-10-nic and your settings and customizations, etc.)
... and probably immensely proud of their ignorance. Just yesterday, a colleague was remarking that the big influx of non-technical people into IT management during the late 90's continues to plague us. I recall a meeting where a simple network issue got dumbed down to the point where a systems person got confused and had to have it restated to them in more precise technical language.
We expect business grads to know about standard deviation for most roles, is it really so much to ask for them to learn something about networking and systems if they're going to work in IT?
"We expect business grads to know about standard deviation for most roles, is it really so much to ask for them to learn something about networking and systems if they're going to work in IT?"
You have some rather strange ideas about life in the corporate world...
I was talking to the one of the guys in charge of the IT department of a central London council (I forget which one, this was years ago). We were both talking about qualifications. His qualifications for his job? A little experience doing IT support and a theology degree.
First, I have seen worse.
Second, it is sort-a normal. It took me a while to explain this in more than one large valley company that software installers should not be done in Bangalore because there the "great developers" consider it under their stature to do them and they end up being handed to the least qualified of all interns - the one which usually does not even do software, but does gophering the coffee.
Install, especially a non-embedded one on a multi-purpose system is something that requires qualification on par (if not greater) with developers to do. This is valid even in this day and age when dh_* does half of the work for you. You need your Tier 1 developers on it or even better a sysadmin with a developer background (if you can find one), not the Tier F ones.
Agreed. The installer is not large, but it is usually running with unusually wide privileges and usually attempting to perform fairly wide-reaching actions. You need to know what you are doing and you need to play nicely with the BOFHs. Both of those require experience.
Nah, you don't have to be a pro developer. A mate wrote the install and deinstall scripts and did the whole packaging for a latex document class we developed together for .deb-systems. Yes, he is really bright, but not a software developer. He can read man pages and understand them and is OCD enough to obsess about little details until they are correct.
I'll buy him another round next time we meet ----->
Nah, you don't have to be a pro developer.
Actually, that's right. I've known people who were InstallShield gurus* who couldn't write a line of code, yet know where all the registry keys live for things, the "right way" to install stuff... it's knowing how the system works that's the main thing, not necessarily how it's written.
I'm actually encountering this on an open source thingy I'm writing. I can write the code, no idea how to get it installable (yet). *sigh*
* I was going to say "wizards", but that would conjure up a totally different image...
"I'm actually encountering this on an open source thingy I'm writing. I can write the code, no idea how to get it installable (yet). *sigh*"
Here's my suggestion (assuming it's Winders):
a) avoid shared components. static link everything (including DLLs). Don't use ".Not" or rely on it being there.
b) install your application into a predictable directory. Allow it to be wherever the user wants it to be.
c) use only simple keys in the registry, all under HKCU (abbreviated), and only if you MUST. If the user wants a system-wide install, add an option to make it HKLM. Your code can check for both. Under NO circumstances do you need to pollute the registry with even MORE 'cruft' than it already has in it!
d) think "how would I do this on Linux". It's probably correct for Windows, too.
e) document type associations aren't all that hard, but I'd just look at a few examples to see how it's done (etc.). Fortunately they're all in the same place.
f) let the application do the 'setup things', not the setup application. I suggest a "/s" switch to the application (or similar) to do 'setup'. Similarly a '/u' to do 'uninstall'. The application can then clean up its own mess.
At this point the installer would be simple: a) copy the files to the right place, b) run "application.exe /s", create some kind of an icon [however THAT process works nowadays, win-10-nic being what it is], make a registry entry for 'uninstall' so it shows up in the list o' installed things, and you're done. Uninstaller could be a very simple application to run 'application /u' and remove the application registry entry and installed files.
Years, decades ago even, I wrote an installer for windows, which never sold. I guess people were willing to tolerate InstallShield because it was FREE, as well as other overly-complicated installers. It was worth doing for my own stuff and for this one customer, though. So eventually I open sourced the thing and put it in github. It's there, just look for 'setup' utilities for windows. You'll find several others, too. I'm not the only one who wrote an installer that's simple and makes sense. This is a VERY common problem for WINDOWS applications, after all.
On Linux and other POSIX systems, installation is very simple. You don't have a @#$% registry to deal with. (there may be a package system, but those are distro-specific). You can put things in your ~ directory and just add ~/bin to your path, and install 'whatever you want'. Sometimes '.local' or similar is supported for various settings files. It's really not that hard. You don't need 'root' to install something. You just need BRAINS. (and you DO NOT need to screw up SYSTEM FILES like '/bin/sh'!!!)
"Nah, you don't have to be a pro developer. A mate wrote the install and deinstall scripts and did the whole packaging for a latex document class we developed together for .deb-systems. Yes, he is really bright, but not a software developer. He can read man pages and understand them and is OCD enough to obsess about little details until they are correct."
Yeah, because man pages cover all unexpected eventualities and gotchas and can easily substitute for years of on the job experience.
*sigh*
And people wonder why there are so many monumental cockups occuring in IT these days.
> A mate wrote the install and deinstall scripts and did the whole packaging for a latex document class we developed together for .deb-systems
Although I was a packager for perhaps a decade, I always struggled with .debs for some reason. Well done to your mate.
At a guess, tens of scripts were written with #!/bin/sh and bash-isms, then the whole thing blew up on a distro where sh != bash.
This was the easy fix. Of course, if they only had have some tool which could automatically search& replace across a large number of files...
"instead of writing their scripts with #!/bin/bash at the top."
Or, how about THIS instead: a wrapper script that checks 'which bash' (or some similar query) and invokes THAT instead, and announces "you have to have bash installed" if it's not on the system [possible for a POSIX system, like FreeBSD].
very, very, very NARROW and short-sighted thinking was involved in the writing of that install script.
I also might add 'arrogant' 'smug' and 'superiority complex' but I don't know for certain what their motives were at the time... [however if I guess correctly, these should apply as well]
Embrace. Extend. Extinguish. Looking closer to TRUTH every day!
What annoys me here is the sheer pointlessness of the installer script. I have installed Microsoft R for one of our users and discovered to my joy and amazement that the tarball package contained a script plus actual, honest to goodness RPM and DEB packages. All the installer did was throw up a "Click to agree to license" thing then install the packages.
I agreed with the licence anyway, so simply ran a yum localinstall <package>.rpm on the system. Job done.
If Microsoft have done their job correctly and written a correct spec file for their RPMs, then upgrading ought to be just a matter of repeating the above actions and letting the system's inbuilt package manager do the heavy lifting of removing the old version and installing the new one; there is simply no reason to even think about an installer script if you do things the right way with the system-supported packages.
If you're not going to package things the way the system package manager expects, then why on earth not?
"You need your Tier 1 developers on it or even better a sysadmin with a developer background (if you can find one), not the Tier F ones."
In fact, forget the Tier 1 developer. It's strictly sysadmin territory. Get it wrong and it'll be sysadmins pointing and laughing.
First, I have seen worse.
Beat this.
WHen I worked for MCI they had MS make them a custom version of XP.( For the right amount of money the will do any thing)
How custom? Enough that they put common used .dll in non standard folders. I did not know this so trying to use a standard XP CD to fix things went fubar. Some times you hand to manual register .DLLs Lord have mercy if you tried to install non company molested software.
When will we wake up, and finally realize the whole picture of the M$ work??
R language is extended atm with incompatible M$-only features, that work only on SQL Server and Azure. Remember when M$ did that to Java with incompatible MS Java, Visual J++ and C# or with C++ with incompatible VC++ 6.0.
Linux, Linux Foundation, R, Git, Atom/Electron, MariaDB, Python, Mozilla, RedHat, Debian, Gnome, KDE, ... are all being "disrupted" by M$. Their trojan horses infiltrate all important open source free software foundations and companies (EEE Nokia style). (M$ is a sponsor to all of these foundations! And Linux Foundation congratulated M$ for buying Github! WTF) M$ wants us to be addicted to their DRM SaaS cloud. Own nothing, pay subscriptions for everything, become a slave.
Say no to monthly subscriptions, choose "old-school" pay once. Smart people like Mr Quest (of CNN business fame) personally don't buy subscriptions (no Prime, no Netflix, no Office365, he says).
It is already getting harder and harder to buy products like cars, tractors, trucks, shrink-wrapped-"offline"-software, DVDs/Blu-rays, etc. And subscription/cloud/SaaS based business models are on the forefront. Evil empire M$ with Gates in the background and the hollywood movie mafia have their big EEE play to destroy vanish free software and the liberty and right to free speech of normal human beings from the landscape.
Well, if you don't like what they're doing, either persuade people to ignore their contributions or take those projects closed-source so they can't interfere. And whilst you're at it, get RedHat nuked from space with fire (systemd, gnome, etc).
I have observed several times that some parts of the open source community, whose entire ethos is supposed to be "take our code and do what you want", is not above criticising people and organisations who then go and do exactly that but in a way they don't like. Well tough luck.
Other parts of the open source community seem very grateful for the things MS are doing. Their extensions to GIT are most welcome indeed, a true bonus for everyone. And someone has to fund github's servers, staff, etc. Have you been paying for a subscription? There is no such thing as free. Someone pays.
'Say no to monthly subscriptions, choose "old-school" pay once.'
AC is absolutely right about this. There's no customer benefit at all to the subscription model. Arguably, it's all downside. Your ownership of the software is in doubt; you end up excessively dependent on net connectivity; intrusive "upgrades", "updates" and "security fixes" disrupt your work and sometimes destroy it; features and UI elements change under your feet like quicksand; the model is often an excuse for unnecessary data slurping and invasion of privacy; you end up paying more in the long term; and sometimes you end up paying for something you never needed. Look at Photoshop: now that it's "affordable" monthly, eight of 10 users are people who would have balked at the licence price and discovered software that does everything they need for nothing—and are instead paying for a suite that has features they'll never even know about, much less use.
For the corporations, though, the marketurds propagandise illusory "benefits" while the entire operation is geared to entrapping customers into a state of dependence, helpless while their wallets gape. The likes of Microsoft and Adobe have taken the essential entrapment concept of the "free" model of Facebook, Google and other monsters, repackaged with subscriptions: you aren't a customer: you're prey.
Whenever you hear someone talking about this or that "ecosystem", think: pit of punji stakes.
Hello:
Linux, Linux Foundation, R, Git, Atom/Electron, MariaDB, Python, Mozilla, RedHat, Debian, Gnome, KDE, ... are all being "disrupted" by M$.
Indeed!!!
Thank you ...
Finally some clarity and common sense.
I cannot grasp why people in IT don't get it and insist with MS and all the crap it spews.
I do not let anything MS in near my Linux rigs.
O.
"Evil empire M$ with Gates in the background "
I don't think Gates cares anymore. He's taken his money and gone and I get the feeling he more or less washed his hands of MS when he stepped down as chairman. Obviously saw the writing on the wall and didn't want to go down with a sinking ship. And credit to him he's actually spending his money on worthwhile causes unlike Larry Eillison who seems to think buying yet another yacht is the pinnacle of lifes achievements.
> R language is extended atm with incompatible M$-only features
I use R very much, and my first reaction to this article: WTF is that POS "Open R"??
The question is not what, but why? And the answer is simple. M$ brings forward their toxic commits to GNU R, which are rejected for very obvious reasons. Then they create their own thing. Relax, the abomination is contained.
By the way, I would like to thank M$ for aptly naming this creature of theirs.
Open R == open source
GNU R == free software
Even though the source of this "Open R" is out there, its sole purpose is to facilitate the integration of proprietary technologies.
This post has been deleted by its author
"Replace cmd with powershell on your system and see how it runs."
There's an option in Win10 to do just this for the start menu. It works just fine.
(Powershell will execute valid cmd commands, plus all of it's own, so it's a drop-in replacement)
And has this noticeable delay when opening, lags when using Tab autocomplete, lags when hitting Return ...
Machine in question is running an SSD, with enough RAM, and an adequate chip ... but wait! Why should machine specs be considered when running a damned command interpreter!
Bash, dash, whatever-sh, CMD.EXE, heck, anything, doesn't do that.
The only other program that does think is Linux systemd's systemctl! Am I too superstitious to suggest a coincidence?
Am I too superstitious to suggest a coincidence?
It's not a question of being supersticious.
I just don't think it is a coincidence.
Coincidence:
A remarkable concurrence of events or circumstances without apparent causal connection.
Do you really find it remarkable that a MS install script seems to behave like systemd?
O.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
