Subject: Re: Open-source'ish linux tablet with atom cpu from Jolla
Mon Dec 01 2014 07:10:34 EST from the_mgt @ Uncensored Subject: Open-source'ish linux tablet with atom cpu from Jolla
Tablet from the makers of the Jolla phone, 229$ including shipping. (The 189$ was for early sponsors on indiegogo)
Edited for the cliently challenged.
Midnight does not seem to have arrived in this timezone here.
The only thing that will eventually do you in is a physical hard disk failure, or breaking the screen, or needing a new keyboard. The screen and keyboard are easy to handle for at-home use - just use an outboard screen and monitor. I do that in Auburn where I visit, and the laptop sits off to the side, "out of sight out of mind", so when I sit at the desk to use it, it's the same (to me) as if it were a desktop machine. Runs Win7 - but has a linux setup using VirtualBox - and I swear the linux install under the virtual machine is faster than Win7 running "native."
In many ways it's just because linux handles things ***much*** smarter than WinBlow$...
Linux and it was decent but because I had trouble with libraries. I couldn't run the programs I wanted to run.
Dispite puppy help searches none of the suggestions worked. feh. So I will try Mint again but I need to find
what causes the slow downs. At first I thought it was Mate but I think it is when the system tries to do a
bunch of stuff. It becomes unuseable.
My XP install was very lean and very fast, owing to years of knowing what you can safely turn off or remove. It is remarkably secure if you don't need it to network with any other Windows devices. Mint is not so lean not fast, but much More pleasant to use.
unless you pay the protection money for the AV, then no windows is fast anymore.
Use a distribution which does not come with a heavy windowmanager/desktop environment on an old laptop. Avoid Gnome and KDE, try one of those ulgy "box" window managers, XFCE, enlightenment or what else there is. Most of the KDE/Gnome programs will probably run fine, only things that rely on all the bling from those desktops might fail. Avoid their filemangers like a plague.
For real snappy feeling, find a distro with BFS (Brain Fuck Scheduler). Feels like cutting snow with a blowtorch. https://en.wikipedia.org/wiki/Brain_Fuck_Scheduler#Adoption
Manjaro, Sabayon, Zenwalk and PCLinuxOS use it.
Linux has *always* been faster than Windows.
The problem is that contemporary linux development has led toward more and more "extras" that really do *nothing* to add to the efficacy and utiility of the *operating system* but just to the "flash" and, quite frankly, the bullshit that integrates with the (various different) window managers.
the_mgt has hit it right on the head. It's the "bells & whistles" that some developers seem to think are more important than anything else are *not* what makes linux superior to just about anything else in existence today.
*That* job is handled by the kernel and core applications.
And *that* job is, in my opinion, most likely as far along as is currently possible.
I'm sure you can nitpick what I've just said; and no doubt some will.
And I'm equally sure that in the not-so-distant future, there will be kernel developments (no doubt matched to CPU advances) that will make linux even better/faster.
The single most important factor for me is speed.
This, of course, assumes the platform to be stable.
But then, just about all linux distros are stable.
And if you strip out the fluff, they are also all fast.
It's the window managers that introduce most of the slugginess. And that really only manifests itself from the GUI (X) side. The CLI on every linux box I've ever used is fast. Very fast.
yea, and if you've ever used cygwin, you know that the tab-expension is realy slow over there... since stuff all nice to the os on linux weirdy fails on the wintendo and brings everything to a grinding hold.
I like some bling and bells&whistles on my linux machines alongside of the fast speeds. I always preferred enlightenment/e17 (and previously e16) with my machines, because they at least tried to look good while staying out of the way. I hate these openbox/fluxbox minimalist things. I also love to have automounting for usb disks and some comfort. What I do not need is another audio system or a new init version or a reinvention of handling of pluggable devices and X autoconfiguration.
But part of the sluggishness on normal desktops is due to the kernel itself, or rather the default scheduler. Con Kolivas build his brainfuck scheduler because of this. On a normal 1-2 core desktop computer, the schedulers in the kernel performed like a sloth. So he wrote his own and it does really make sense on a desktop, were realtime interaction and quick responses to user interaction is paramount. He reported that to the kernel scheduler guys and they said "can't reproduce on my octacore 16gb ram machine."
The box will do *nothing* else; it will even "hand off" DNS to the main linux box.
It will be blazingly fast; hell, it was blazingly fast the last time I tried this back in the 1990s - so it can only be better/faster today than it was "back in the day."
Dec 7 2014 6:05pm from IGnatius T Foobar @uncnsrd (Uncensored)
People *are* re-learning the art of efficiency in system deployment.
We have the Raspberry Pi to thank for that.
Yeah - sort of like it used to be when programming for pre-winBlows DOS...
"Watch that executable - can't exceed 128K!"
the_mgmt, I agree E17 is fun. IG, yes, the cheap Rpi does make you think of the mantra: Do one thing, and do it well :-)
"Watch that executable - can't exceed 128K!"
Back when I first started developing Citadel on a unix platform I was running an early version of Xenix, and the compiler had a 64K code + 64K data limitation.
Little did I know that I was facing a Microsoft stupidism, even then, even on a "real" operating system.
Microport ended up being better. Who knew.
All things considered it was a good development system, at least for its day. I have *no* idea if they (Borland) even still exist.
The limitations were imposed by DOS (3.x at the time) - 128K for the executable after compiling. As far as I can remember (it *has* been almost thirty years!) the compiler handled all data issues internally while compiling.
I had the machine "populated" with 640K of RAM. Remember? A memory card. 8 sockets by 16 sockets if memory serves, and you had to place a chip in each socket. I think. It's been forever-ago... ;)
This was a machine running an intel 80286 CPU with a "math coprocessor" chip. IBM PC/AT architecture (it was a clone).
They just don't DO that any more! (good thing)
SO HAPPY to see that TigerDirect has a small selection of laptops available with Linux on them!
I've never used "Linpus" (sounds like something that would come out of an infected penguin) but I can always reload it with something else. Not one dollar of my hard-earned money will be sent to the Great Satan of Redmond!
Ideally I'd love to support a company like System76 but they just don't have anything in the low-end range, and this is for a family member who will abuse it.