Fedora cooks up new Linux for Raspberry Pi Raspberry Pi users have another operation system option, after the folks behind Fedora Linux changed their recipe and issued a “remix” of the OS for the tiny computer. Pidora 18, as the release is known, is not the very first of its kind, as two previous versions are available but weren't optimised for the ARMv6 architecture. …
Reason I use vi.
I figured sooner or later I would encounter a broken system without my preferred text editor, and EVERY *nix system has vi.
It happened about 3 months after I made the decision to embrace vi. An old Solaris system that I had inherited with the job, decided to fail on a Wednesday afternoon. Payroll was run on Thursday, and of course the payroll system was tied to that Solaris box in a way no one understood anymore. (System was built by the guy who left before the person I replaced.)
Took me a couple of hours to figure out what was going on, correct the issue, and get a working system again. It would have been a much longer process if I had not gotten comfortable with vi.
I was a hero to the payroll people. :)
vi for ubiquitousness.
"vi for ubiquitousness."
Ummm, ubiquity, I think. Either way, I agree.
Once upon a time I used VAX/VMS. I customized EDT (the original, not the broken TPU emulation) within an inch of its life. Which left me with problems when I had to use somebody else's login to show them what to do, because none of my clever tricks worked (worse, some of the keystrokes I'd defined they'd defined differently with hilarious results).
Which is why I no longer try to customize editors. Why I avoid emacs like the plague (I know I'd customize it to hell and back and I can't afford that luxury). Raw vi. Well, maybe not the raw vi cygwin gives you if you don't touch .vimrc, but otherwise unadorned vi. It's a crappy editor, but it's a KNOWN CONSTANT crappy editor.
It works the same on all the systems I deal with. CentOS. Ubuntu. Cygwin on various flavours of Window$. Even the bastardized flavour of Debian on ReadyNAS. If I ever have to deal with some other flavour of *nix I'm confident that vi will be the same. Just as tedious and unpleasant and unproductive to use, but consistently so.
vi for the win!
vi has saved my life a few times for the same reason
vi will run on even the most ancient systems, over the oldest crustiest dumb terminal
nano gives me the shits & I hate that Debian now makes it the default editor
First thing I always do is purge nano from every machine
I will admit that vi is a shit to learn; but once you've come to grips with it you won't want anything else :)
It's not just the "it's there" - which of course is enough of a reason (managing 4000+ servers with a mix of 4 flavours, multiple versions of *nix, plus all the mini roots/console/single user varieties), but it's also the times when you're working with a different keyboard, unmapped keys (or termcap files), no cursor keys? no 'End' no 'Home'? no problems! hjkl, no dos2unix? %s/.$//g need to add/remove some binary? control codes?
I've tried, over many years, myself.
Fact is, it's quicker to download, compile and install something like nano or pico than it is to faff around with vi. And they are at least half-intuitive.
Sure, I can edit a crontab in vi and know how to do so and write out the resulting file, but really? What a pain in the backside.
I've used ed and ex nearly every day for over a third of a century. Mostly in scripts. But my goto for shifting ASCII from my brain into my computer has been vi (with the help of a Model M and a serial attached so-called "dumb" terminal) ... to the point where I have a user-name "write" that uses vi as the shell. When I'm writing (code, documentation, contracts, dead-tree letters), I don't like distractions.
This post has been deleted by its author
>>I would never had thought it as a easy text editor.
None of the better ones are easy. If you want easy, use KWrite (even though you can use VIM methods with KWrite as well, and [I think, correct me if I am wrong] Emacs chords). And don't get me wrong, I'm not hating on KDE or anything, I've only been using it 10 years since I first tried a Linux Distribution, but for a simple text editor KWrite just works. I'm sure Xfce, Gnome, LXDE, MATE and such all have something like it as well.
But yeah, Vi and Vim may be odd sometimes but they sure as hell beat the strange button combinations and chords in GNU Emacs, though just to make it clear, vim (and the predecessor, vi) does have their own weird quirks to their respective programs as well.
Some users also find Emacs easier to use, though I'm not entirely sure how, as sometimes its like playing twister or Beethoven on a computer keyboard. Emacs's combination obsession really makes me wonder if RMS or one of the senior GNU developers was ever a pianist.
If you want to get the best out of Emacs without learning all of the meta key combinations, you need to learn the Electric modes. Once you get the hang of them, Emacs can be a doddle.
The reason why vi (pronounced vee eye, not vie or six according to the yellow book) is a little hard to use is because it dates back to a time when the only keys that you could guarantee were on a terminal keyboard were the alphabet and number keys, a limited amount of punctualtion, as well as an ESC key and a control function. As long as the terminal had a program addressable cursor, and a small number of other features (and really not too many of those), and a termcap definition (yes, termcap in the original BSD, not terminfo), vi would work.
There were some terminals that were too broken, however. I remember comments in the original BSD termcap about some beehive terminals, and a Ann Arbour Ambassidor that were deemed just too brain-dead to be able to write a meaningful termcap entry.
HP, in their infinite wisdom, had a serial console that you were supposed to use for console access to their servers. The only problem was that the UK version never had the '#' key.
For those not familiar with 'nix the '#' character is used to comment out lines in config files and, more importantly, as part the "shebang" sequence (#!) in the initial line in scripts. Not having one on the keyboard can be a severe handicap when trying to get a server back online.
I still run termcap, works better for some of my older kit and older code that's hardwired for it. Part of the reason I run Slackware is that it's still BSD-like instead of SysV-like, although you can also use terminfo with Slack. For a trip down memoryNightmare Lane, dig through /etc/termcap-BSD. For example, this entry:
# 9.11.2 (Tue Nov 7 00:21:06 EST 1995):
# * Exiled some utterly unidentifiable custom and homebrew types to the
# UFO file; also, obsolete small-screen hardware; also, entries which
# look flat-out incorrect, garbled, or redundant.
The UFO file would probably be fun reading today, but I never bothered back in the day. Part of my job back then was tracking down bugs in the BSD system scripts; reading them for fun was out of the question! :-)
My journey was V6->V7->SVR2->SVR3 and onwards, so I was mostly isolated from BSD (I did have a BSD 2.3 or 2.6 distribution for my non-I&D PDP11 running V7, for Ingres, and it did have vi on it, but it would not compile in 56K, even using the experimental overlay loader that was also on the tape (this used one segment register in the PDP11 to switch different 8K pages into the process text address space to allow you to have more than 56K of memory in an executable, and it required a new system call to be added to the kernel to allow the dispatcher routine to request that the correct page was mapped in to the process before actually calling the code).
I only really came across vi when I moved on to SVR2 (I had used an Ultrix machine before, but not too much). Up until that point, I had been using ed almost exclusively (although I did also use an extended ed editor called em, tagged as Editor for Mortals which I believe came from Queen Mary College in the UK [hint - watch you don't mistype the "e" as an "r", very annoying])
For some time, I worked for what is now part of Alcatel-Lucent (then AT&T and Philips Telecommunications), and became the terminal 'expert' in their UK system support team, so was intimately acquainted with terminfo (it was SVR2&3 after all), and to a lesser extent termcap (some of the AT&T exptools packages used termcap, even though terminfo was available on almost all systems), and I looked after many different terminal types including AT&T 4425, 5620 and 630, HP2932, adm3 and adm5, Wyse 30 and 50s, almost all DEC terminals from 52s to 420s and compatibles, and even on ibm 3151 (yeugh). I missed out on the days when you had to encode time delays in the various commands, however.
While there, I also had a source-code license for Gosling Emacs, which had it's own (buggy) termcap.
The youngsters of today really don't know what it used to be like. I still get really annoyed when I see people hard-coding ANSI escape sequences into programs rather than using termcap or terminfo, or even Curses. It's just wrong!
Am I alone in preferring joe over vi? I know, the wordstar-like commands clearly demonstrate my age but I find it SO much easier than vi. It's also laziness, not wanting to learn a new set off key sequences!
Also, a tip of the hat to Slackware since they're mentioned above. Slackware user since 1993.
Paris as we're talking about something easy to use.
If they stick to how mainline Fedora goes, immediately after 19 is released (July 2nd from what I understand) you'd have to upgrade if its based on Fedora 17 because Fedora 17 will go legacy at that point and lose support.
Their breakneck speed upgrade schedule isn't for the faint of heart or for people who don't like to test. Remember that Fedora is RHEL's upstream for all intents and purposes, Red Hat Inc. doesn't come right out and say that anymore AFAIK, but it is the case. Not everything makes it, a good portion does.
Fedora isn't for everyone, I like it because I have a light QA background and because Fedora is among the first to get the newest stuff that'll eventually be in RHEL as I said, and given RHEL is the vast majority of the reason that I can afford to pay rent AND eat, it certainly behooves me to know how to use new tools and features when their original iterations come out if they wind up in RHEL or CentOS.
But not everyone likes that, and I'd never use Fedora for production, dear God no, its gone wrong on me way too many times for that. Test, Education, and desktop use are great with Fedora, but not a production server. But really, if you want ultra-stable Red Hat type distros, there are always CentOS, RHEL and Oracle Linux. Or you can switch factions and use Debian, or really go off the reservation and use a BSD. I love GNU/Linux* (though I am OS Agnostic. In my jobs I have to be I use Windows, GNU/Linux, BSD, a proprietary UNIX, and z/OS a lot as well as some shit that I don't even know what the terminal is really running on. The Army Reserve, my other job, has some ancient and/or interesting equipment as well), but for me OpenBSD and later FreeBSD was my first UNIX-like love, and I'm surprised more people frustrated with certain things about Linux don't try it. Apple's Darwin must really turn people off or something.
Anyway, I wonder if fedup works on pidora. Does anyone know? The article says it has most of the RPMs in the official repo and that yum works, but not a word about fedup, and any Fedora user sure as hell wants to know if fedup works because we'll be upgrading, and soon. If it does have fedup, then upgrading's pretty easy. It works much better than PreUpgrade did (or didn't, as in my case every time I used it).
“The GUI in particular is slow, because the 2D graphics (the X Window System) are not yet connected to the 3D graphics processing unit on the SOC.”
If you're the kind of crackerjack wanting to install Fedora on a RasPi, switching to the soon to be released GPU-accelerated Wayland stack over X should be absolutely no bother. Once you take the 2d GUI drawing + compositing jobs out of the equation, the machine really begins to shine, as anyone who has been using it without a GUI should know.
... I don't really care what OS or editor anyone but me uses ... as long as it's right for you & your current project's needs, use it. Same for hardware platforms, telephones & etc (cars, bikes ... ). Arguing over "which one is over-all best" in this kind of thing is a fool's errand. And I should know ... I frittered away gawd/ess knows how many hours in the vi/EMACS wars back in the day, and then even more time on the C/C++ flame-wars on Usenet. Total fucking waste of time.
Advocate what you like, but don't bad-mouth what somebody else is using.
"The GUI in particular is slow, because the 2D graphics (the X Window System) are not yet connected to the 3D graphics processing unit on the SOC."
Why include the GUI then? It's taking up storage space.
Really, if it's not ready for prime time then just don't release it.
Released because it works well enough - being a bit slow is not the same as being full of bugs.
Also turns out that accelerating X with things like OpenVG and OpenGL is almost impossible, as X really doesn't lend itself to it, with lots of very small pixel operations, and of course, if your app is doing lots of rendering in SW, you cannot accelerate that anyway (unless the app actually uses OGLES or OVG). Best you can do is whole window operations (compositing etc) which actually doesn't use that much CPU compared with, for example, a HTML renderer.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
