Slashdot Mirror

I am wondering since a long time, why the Arch wiki does contain so much more (high-quality) content than the Debian wiki, although the developer and user base of Debian should be much higher.

One reason also here could be infrastructure. The Arch wiki

-> https://wiki.archlinux.org/

is a mediawiki instance, which looks much more attractive than Debian's wiki

-> https://wiki.debian.org/

which is a moinmoin wiki instance. I can understand that the motivation of users and developers is higher if they can create something beautiful.

Are the other reasons for the quality difference?

https://wiki.archlinux.org/ind...

Depends on the device. I have the GPD_Win first generation, Arch linux ran fine except for having to change a bios setting and putting a couple of files in the firmware folder for Wifi. YMMV however, no idea about any of the other GPD line.

https://www.archlinux.org/pack... 3.0.4-7 on the rolling distro.
https://snapcraft.io/vlc 3.0.5-1 on the snap.

I don't disagree that the rolling release is faster however it is not the latest and may be slightly missing the point. This is the same point why I'm happy to delay feature releases to Windows 10 as long as possible and run Ubuntu 18.04 LTS on my system. The complete underlying system should remain as rock solid and stable as possible, the opportunity to install the latest and greatest piece of *individual* software however should not be impeded.

That is the problem snaps solve. You risk stability by adding non-sanctioned repositories to your distribution. You risk stability by going with a distribution that rolls out everything as quickly as possible (look at the fuckup that was Arch's systemd migration, compared to the non-event that was Ubuntu 16.04 LTS).

I'm not saying everything should be a snap, I'm saying they are very useful and solve an existing linux problem.

If you have to use WIndows upgrade to pro under "This PC" and enable Hyper-V. It supports Linux and even FreeBSD at the kernel level without guest tools automatically.

Uh, no. Integration components is MS's term for guest tools and are automatically installed. Linux has its own tools which MS went out of its way to make sure were compatible with Hyper-V. Linux also has native support for its own para-virtualized devices, its term for guest tools, so it supports KVM "natively" since many, many years ago. For Windows, you install guest drivers. In short, you don't get out of using host to guest drivers.

Both KMS and Hyper-V are type-1 hypervisors unlike the shitty VmWare Workstation and virtualbox. No guest tools and run bare metal near native speeds.

Unless you want to be able to use a Windows VM on Windows, move it to Linux, then move it back again. The only reasonable way to get near native speed without guest tools is to do hardware pass-through, and that's generally not worth it for anything but graphics cards and possible network cards. Seriously, argue at least something sensible like standardizing on guest tools across KVM, Hyper-V, VMware, and Virtualbox to make it all pretty moot. Don't spout bullshit.

Its always been the same issue, over and over and over. If you need sources for 3rd party closed drivers, you cant update the kernel without them.

This needs to be fixed. This will fix everything, older android can be updated, linux systems like phones and tablets can be updated, forever.

This problem has already been fixed and was fixed a ***long*** time ago by driver vendors simply providing a loadable kernel module that interfaces with the binary driver. We have been doing this for well over a decade now and in recent times it has become automatic thanks to DKMS.

So no, you don't need the sources for 3rd party drivers, this has been fixed and was fixed long ago and no, it didn't "fix everything".

I wonder if Dropbox (not the article author) means encrypted ext4. ext4 itself supports file-level encryption since linux 4.1.

https://wiki.archlinux.org/ind...

That has its own ioctls and policy management.

I've been using linux on a dell latitude e7270 for over a year now and my battery lasts more than in windows. The trick is to configure it properly. In arch linux https://wiki.archlinux.org/ind... and I think you can get those in other distros too. With those and the standard battery I get between 5 and 10 hours depending on the workload.

By reading the pkgbuild file, which is just a shell script that defines some variables and functions for makepkg to use when building the package. Go take a look yourself, the PKGBUILD files are all pretty easily viewed through your browser.
Unless you're talking about the package sources being compromised, which would be a much bigger problem, and disingenuous to pin on AUR itself.

https://lists.archlinux.org/pi...

According to posts on aur-general, the known affected packages are:

• acroread 9.5.5-8
• balz 1.20-3
• minergate 8.1-2

According to comments on the AUR acroread package, the script the compromised package installed (to upload system details) contained an error and wouldn't function properly. The script also installed a systemd timer, and the comments advise checking your system for:

• /usr/lib/xeactor
• /usr/lib/systemd/system/xeactor.timer
• /usr/lib/systemd/system/xeactor.service

As a side-comment, for those unfamiliar with Arch, these compromised packages are not part of the official Arch repositories. The AUR is a "user repository": a collection of user-supplied packages which require deliberate download and installation. AUR packages should [i]always[/i] be reviewed before installing them, and not installed if you don't trust the package. As the AUR documentation explains, "Warning: Carefully check all files. Carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list."

According to posts on aur-general, the known affected packages are:

• acroread 9.5.5-8
• balz 1.20-3
• minergate 8.1-2

According to comments on the AUR acroread package, the script the compromised package installed (to upload system details) contained an error and wouldn't function properly. The script also installed a systemd timer, and the comments advise checking your system for:

• /usr/lib/xeactor
• /usr/lib/systemd/system/xeactor.timer
• /usr/lib/systemd/system/xeactor.service

As a side-comment, for those unfamiliar with Arch, these compromised packages are not part of the official Arch repositories. The AUR is a "user repository": a collection of user-supplied packages which require deliberate download and installation. AUR packages should [i]always[/i] be reviewed before installing them, and not installed if you don't trust the package. As the AUR documentation explains, "Warning: Carefully check all files. Carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list."

According to posts on aur-general, the known affected packages are:

• acroread 9.5.5-8
• balz 1.20-3
• minergate 8.1-2

According to comments on the AUR acroread package, the script the compromised package installed (to upload system details) contained an error and wouldn't function properly. The script also installed a systemd timer, and the comments advise checking your system for:

• /usr/lib/xeactor
• /usr/lib/systemd/system/xeactor.timer
• /usr/lib/systemd/system/xeactor.service

As a side-comment, for those unfamiliar with Arch, these compromised packages are not part of the official Arch repositories. The AUR is a "user repository": a collection of user-supplied packages which require deliberate download and installation. AUR packages should [i]always[/i] be reviewed before installing them, and not installed if you don't trust the package. As the AUR documentation explains, "Warning: Carefully check all files. Carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list."

He was caught within a few hours, because all changes all public:

https://aur.archlinux.org/cgit...

Possibly bad guys would rather add trojans to iPhone and Android apps, which may stay in the store for months without detection. You can't tell what changes have been made to compiled apps you download on iPhone, Android, or Windows.

features a 10-inch display, integrated kickstand, and Windows 10

I guess the foam helmet is extra? :P

p.s. When you're ready to remove the training wheels, Linux will be waiting.

I have an ASUS EEEbook X205ta that has the same.
I'm running 64-bit XUbuntu on it.
I only needed a 32-bit UEFI loader for grub on it to make it work.
Unfortunately, the Linux kernel still has trouble with the power saving modes of the Baytrail chipset, but some workarounds have been made.
Here and here are links with helpful information.

As for Linux it's all very sad - even H.264 is not hardware accelerated.

Hardware decoding of H.264 is supported under Linux through VA-API on Intel GMA 4500, Ironlake Graphics and newer, and AMD Radeon HD 4000 and newer. It is also supported through VDPAU on AMD Radeon HD 4000 and newer and nVidia GeForce 8 and newer. There are adapter libraries available in case you need to use a VA-API client with VDPAU drivers or vice-versa. Accelerated encoding is also supported on certain hardware.

The above is based on the Hardware video acceleration page on the Arch Linux wiki, and my own experience with hardware decoding on Intel graphics hardware with the Debian VA-API drivers.

If you're referring specifically to hardware H.264 decoding support in Firefox, AIUI hardware decoding support has been included in the last few versions but may be disabled by default, requiring some tweaks to the preferences.

I am on a laptop and synclient no longer works because they are using a different touchpad driver. I suppose it is a matter of time before this is the situation on Debian too.

Yes! You triggered the correct memory. I've encountered this. Synclient was superseded by libinput as a more generic system. Try here:

https://wiki.archlinux.org/ind...

The arch documentation for Linux is excellent by the way, even if you don't use arch. TL;DR, you use xinput now, not synclient.

Gnome Shell - the default (AFAIK) for Debian.

I don't use GNOME, but I believe you can put scripts in somethig like .config/autostart

Here's the spec:

https://specifications.freedes...

The documentation has the flavour of the Isla de Muerta: it cannot be found save by those who already know where it it, but now you know too.

I got meself a refurbished ThinkPad X220 for college and portable web development, pimped it out with 8GB RAM and a 250GB SSD and thought I'd try something new off the beaten Debian/Ubuntu track.
Manjaro i3 seemed like a nice candidate. And sure enough, it holds up nicely. Rolling updates (manjaro is arch based) and i3 is a very neat tiling WM that's really fast and nice and easy to configure. The manjaro i3 defaults are nice as is the turquoise on dark-grey design. Technical but still modern and sleek.

Manjaro is the new kid on the block and might just be yet another passing distro-fad but for now it holds up and I'm enjoying it. yaourt is a CLI tool for installing non-standard packages and so far everything I've needed could be found on AUR.

Bottom line: Wanna try something new with i3 as default? Yours truly recommends Manjaro i3. Give it a shot,

Still waiting for other linux distributions to issue a patch. As of this moment, Arch latest is still 4.14.11-1 and is still not patched from the looks of it?

https://security.archlinux.org...

A quality laptop using any OS you like.

That'd be fine if companies still made 10.1" laptops designed to run desktop operating systems.

I have an Asus Transformer T100 that I bought well after December 2012.

As of the latest update to the Debian project's compatibility page for the T100TA, suspend and Bluetooth are "Error (Couldn't get it working)", screen backlight is "Unsupported(No Driver)", and WLAN and audio are "Only works with a non-free driver and or firmware".

Or does "any OS you like" mean "any OS you like so long as it is Windows" in the same way that the Ford Model T came in "any color that he wants so long as it is black"? Does "systems" refer to both Windows 8.1 and Windows 10?

Here's one you can buy for $300. [ASUS Transformer Book T101HA-C4-GR]

Is Linux more compatible with the T101HA than with the T100TA? In this forum post, a user complains about "missing sound."

Uh...there are quite a lot of official documentation repositories you can look at, including this very good one,
https://wiki.archlinux.org/ind...

And this one,
https://access.redhat.com/docu...

Oh, look! In the cleverly disguised "Migration Planning Guide", there is a section titled "2.2.5. Changed mount behavior at boot". And sure enough, it describes exactly the changed fstab behavior the GP experienced.

the security of a "modified" system (based on an SELinux kernel) depends primarily on the correctness of the kernel and its security-policy configuration.

The weakest link by far is not the security-policy configuration.

No, I think you are wrong. From this website describing Yubikey:

https://wiki.archlinux.org/ind...

I found this:

"Security risks
AES key compromise
As you can imagine, the AES key should be kept secret. It cannot be retrieved from the Yubikey itself (or it should not, at least not with software). It is present in the validation server though, so the security of this server is very important. "

In other words, if the validation server is compromised, they everyone is screwed. This is the same vulnerability that the original poster complained of with RSA tokens and 2FA apps. With the method I described, there would be no validation server, only a database of PUBLIC keys. That would be much more secure.

Once you install the legacy boot firmware blob, you can put it back in regular mode.

According to this page, setting legacy boot as default "requires disabling the write protection".

You can install legacy boot option rom without removing the screw Tepples. :P

Based on the results of a Google search for legacy boot chromebook, such as this and this and this, I'm under the impression that legacy boot can be reached only from developer mode, which we've established is fragile, and it tends to corrupt itself when the battery runs dry. What keywords should I have used to find a guide to setting up legacy boot on Chromebook?

Also, you normally dont need to disassemble the hinge mechanism to get to the screw. It is usually accessible just after removing the back of the clamshell.

That's not the scenario I had in mind. What I had in mind was that the hinge would eventually develop a fault through wear and tear unrelated to the installation of custom firmware, and then a warranty service program trying to minimize costs might notice that the firmware isn't stock and refuse to service the hinge on grounds of having modified the firmware.

That's a major hiccup in driver support : GCN 1.0 Radeon got a "when it's done" promise regarding support by the amdgpu driver.
"Straight" Radeon 7850 and 7870 were good GPUs with the best performance/watt from AMD for a while ; I'd rather want something lower power and that's Radeon 7750 or R7 240.

There's this about installing/forcing amdgpu on older cards (yours is Tahiti likely. you need linux 4.9 and up with support toggled in the kernel...)

https://wiki.archlinux.org/ind...
https://wiki.gentoo.org/wiki/A...

Not really great. But perhaps it will be more ready, or decent enouh in 18.04. The good news is you don't have to worry about "amdgpu-pro" which is sort of a binary blob that plugs onto the open source driver : its goal is more to be a known quantity for CAD packages, etc. rather than be the only good option for games and generic use.

My Ethernet port now shows up in ifconfig as the very reasonable "em0".

em0? Do you mean en0? IIRC, it stands for Ethernet Network #0. IRIX uses (used) the same network naming scheme as well.

Pedantry aside, I sort of understand why the do the funky name scheme. The idea is that the name is based on the location of the slot, so PCI/PCIx slot #0, so that's where the p0 comes from. The s19 is a unique identifier based on some properties your card has. This way your cards don't bounce around the network names. However, some problems arise due to wireless cards identifying themselves on bus -209, so you get wireless names like wlx32559s18 and so on.

ArchLinux has come up with a way to deal with this, so long as you stay away from the standard eth0 (I use en numbers myself). It should work in the other Linux versions, also, but I've not tried it. Here's the link. That said, even back in the ifconfig days, I used something on a CentOS server these lines to give a specific eth-number affinity for a specific Ethernet port by mac address.

I understand why you've switched to BSD (FreeBSD?), I've used it in the past, back in the late 90s. My suggestion is to track stable, and dedicate some time to the mailing list to understanding what they are doing what they are doing. But don't upgrade stable (build world) without reading the release notes. There was a big deal when one of the stable bumps (like 3.8 to 3.11) broke world if you didn't stop off at 3.9 first. Also, build your own kernel. The kernel config for BSD, IIRC, is a giant text file. You flip the bits that you want, recompile, reboot and you are good to go.

Here is a bit of a summary:
https://wiki.archlinux.org/ind...

Check to see whether xbacklight works. If not try looking at this thread.

In general the arch community seems to be good at coming up with solutions for problems like this.

Have you tried googling?

There is quite a comprehensive documentation available from Redhat: https://access.redhat.com/docu...

Also, Archlinux has always good wiki articles, and systemd one is here: https://wiki.archlinux.org/ind...

One good introduction is on Linux.com: https://www.linux.com/learn/un...

One week ago: https://www.archlinux.org/news/phasing-out-i686-support/

The amazing thing to me is that the linux kernel doesn't even have a testsuite like GCC or binutils (correct me if I'm wrong).

There is a test suite here.

Chromebook pixel.

https://www.amazon.com/Super-G...

It can completely ditch chromeos, and run pure Linux.

https://wiki.archlinux.org/ind...

http://marksolters.com/program...

Like other Chromebooks, battery life is obscenely long.

quote from your link:

Since Budgie is a shell for GNOME, Budgie Remix 16.04 ships with GNOME Settings (Control Center / Settings Daemon)

from ArchLinux wiki:

Budgie is the default desktop of Solus Operating System, written from scratch. Besides a more modern design, Budgie can emulate the look and feel of the GNOME 2 desktop.
At this time Budgie is heavily under development, so you can expect minor bugs and new features to be added as time goes on.

then the user must use Linux to play the blue ray, like described over the net.

Which licensed BDMV player does the net recommend? Google linux bdmv player found this six-year-old post which is a reverse engineered player that's "a far shot from proper native support for blu-ray playback" and likely illegal in my country. It also turned up a page last updated in 2016 stating that "no official Blu-ray player software is available on their system". In particular, free software is on MKB v28 while new movies are on MKB v57.

You are aware that lots (and I mean lots as in every single one) site provides a shopping cart, aren't you?

I'm not referring to the buyer's user interface. I'm referring to the seller's user interface to validate a list of products that the seller is uploading to the online sales platform.

It's 2016. We got Chromecast and Bluetooth keyboards & mouses.

How many people have you seen actually carrying around a Bluetooth keyboard and mouse to use with a smartphone in situations where a laptop has traditionally excelled, such as writing and editing long-form text with markup? And for the use case of taking notes about a web page or other document you're reading, how easy is it under stock versions of the popular smartphone operating systems to make both the document and your notes visible on the screen? Android has had tiling window management since Android 7.0 "Nougat", and Samsung has long had the manufacturer-specific tiling window manager that it introduced with Galaxy Note, but Nougat has yet to become widespread on existing devices or even on devices still sold new to the public.

People code applications for Linux

Or they don't because they see more money in making an application for Windows and not Linux than for Linux and not Windows, or even than for both Windows and Linux due to "support cost issues".

and if they're good the distributions include them (what's one more in 50,000+?).

The distributions tend to include only software under a free software license. The economics of games with professional production values, licensed players for major studio movies, and income tax return preparation software sort of rule out a timely release as free software for reasons I've described in this article.

Good luck running a binary for GTK for Windows or Qt for Windows on anything but Windows.

You realize those platforms came from Linux, rigtht?

Even if an application developer uses a platform that came from Linux, the fact that the platform came from Linux is no help to an end user if the developer chooses to publish only a Windows binary because of "support cost issues".

what I really want out of a desktop environment is to stay out of my way.

Here, have you tried using Awesome?
Ubuntu: "sudo apt-get install awesome"
Fedora: "sudo yum install awesome"
Arch: "sudo pacman -S awesome"

--Best answer I've seen so far, except for the ZFS responses.

--My question is, how has Synology gotten btrfs to be "stable" when it's still considered to be "experimental" on a regular Linux distro? I've seen reports of people losing all their data on btrfs and still consider it to be at *least* 3-5 years behind ZFS.

https://wiki.archlinux.org/ind...

https://lwn.net/Articles/67681...

systemd supports old shell scripts. The easier way is to make a unit file: https://wiki.archlinux.org/ind...

"I tried everything" clearly not. For one thing, this affects all but the oldest chromebooks, so it's not like you're the only one with this issue. ChromeOS does not use a standard BIOS, although it can emulate one. If you want that, enable it. I've had three Chromebooks so far. Mostly I've been using crouton for linuxy tasks, but I was always able to enable USB boot, and once I went so far as to install a full Debian system. It's not that hard, especially compared to the process involved in getting an actual ChromeOS development system set up. I'm not going to say that there may not be some sort of benefit to their tech stack and toolchain, they certainly seem to be doing well on the security front, but for being better-selling than Mac OS in the laptop market, there is practically no development of ChromeOS outside of Google. I believe that this issue and the BIOS issue both stem from their choice of tech stack.

The worrying part is that this seems to be SOP at Google -- it's an open platform, anyone can develop for it, you just have to go down to the basement with a flashlight and some climbing gear, and look for the disused lavatory with the "Beware of the Leopard" sign on it.

https://wiki.archlinux.org/ind...

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

Let me share some wealth of knowledge with you about systemd in the real world. I urge you (and anyone else) "not having a problem" with systemd to please read this actual bug (which a colleague of mine has experienced on bare-metal systems running Debian). Respectfully, read all the replies (there aren't that many). This bug contains a gold mine of insights (into thought processes, beliefs, and actual usability concerns) that should make any worthwhile systems administrator (or developer, for that matter) start shake uncontrollably followed by an outburst of "Are you fucking kidding me?!?!"

Now ask yourself if this is really what you want re-inventing and controlling everything. If you choose "yes", that's OK (really!), but I choose "no".

There is a perception that it is a "borg" which keeps taking over more functionality and becoming a dependency for so many things that there is no choice but to use it, an example being Gnome. I don't know if this is fair or not.

This is effectively the crux of it. Everything else is just a symptom of this. People will make detailed technical analysis of the inner workings of systemd and that's cool and some of them are correct. But, bad technical decisions aren't that big of a deal until they start spreading across the system like a virus. Once systemd has infected everything (and, we are rapidly approaching that), it will be difficult or maybe impossible to cut out that cancer. We are right on the verge of being stuck with systemd and that's a very bad situation to be in.

I will note that maintainers of several unrelated distributions independently chose to adopt it, including Arch Linux. I mention Arch because A) they are famously in favour of a simple base system which you customise the way you want, B) I don't believe have anything to do with Red Hat (where the systemd creators come from), and C) they haven't been forced to switch by e.g. gnome because they don't require gnome or any other desktop.
Comments from an Arch developer on their forum: https://bbs.archlinux.org/view...

This is the second problem with systemd. It has polarized people to such an extent that it resembles a religion or US politics. You must pick a side and you must rabidly defend that side no matter what. To be fair, it's an issue worth having an opinion on but, your opinion definitely doesn't matter. You have distros with very finite resources (like Arch) and distros with effectively unlimited resources (RedHat). The smaller distros kinda have to eat whatever shit sandwich the larger distros serve up because they don't have the resources to do anything else.

Arch Linux uses EFI BOOT STUB which allows you to secure boot with your own keys if you like.

Yeah, that's what my last paragraph is about. You can do that or sign any other EFI bootloader you prefer with any OS you prefer if your hardware allows changing your keys and you know how to do it.

Arch Linux uses EFI BOOT STUB which allows you to secure boot with your own keys if you like.

Yeah, that's what my last paragraph is about. You can do that or sign any other EFI bootloader you prefer with any OS you prefer if your hardware allows changing your keys and you know how to do it.

Thanks for the detail!

Arch Linux uses EFI BOOT STUB which allows you to secure boot with your own keys if you like.

Thanks for the detail!

Arch Linux uses EFI BOOT STUB which allows you to secure boot with your own keys if you like.

I think I'm going to remove the package until a new, fixed version comes out, or at least detailed information on how to migrate the vulnerability until a fix comes along.

The article suggests a mitigation, however it sounds like it may just be easier to remove the package until your upstream provides updates...

James Darnley of FFmpeg suggests that disabling HLS (HTTP Live Streaming) while building the package should do the trick until a fix is committed.
It is also possible to fix the issue by rebuilding the FFmpeg packages without network support, using the --disable-network configure flag, but that seems a bit too much.

A commenter in the arch bug report listing also says:

Btw, one could also do --disable-demuxer='hls,applehttp', but rebuilding without network support looks like a more robust solution for now (until the issue is inspected and fixed upstream).

https://bugs.archlinux.org/tas...

My understanding is the specific bug reported in russian is exploited via HLS, however it is unconfirmed if the same method could be used and exploited in other network stream demuxers yet.

Rsync is simple, lightweight, has been around forever, and gives you incredible power. Assuming by "manage centrally from a console" you mean that you have remote admin access to all the computers in the scope, it's as simple as a cron job running your Rsync script. You can trivially make several versions for different use cases (Linux vs. PC) and only have to configure the setup once in the cron job. After that, you only need to touch it if you make changes.

Rsync can push deltas to any remote server you have access to via a wide range of protocols. The rest of your IT team will appreciate that you're only sending deltas and not sending full copies every execution and hogging bandwidth.

Here's a link to get you started: https://wiki.archlinux.org/ind...

Good luck!

I would agree with this - it's much easier for a lazy admin like me to manage only a few machines that do a lot, vs a lot of little machines that do only one thing. Power requirements are probably lower, even with a few beefy boxes with high-watt PSUs to run 32 displays vs many small machines, each needing their own independent power - especially AC -> DC converted.

You might use separate Xorg instances each launching a browser to a given URL for that screen, but how cool would it be for a large xinerama desktop across 32 monitors, just to play with? Attach 2+ mice/kybd (one for each NOC workstation) to those machines and seamlessly move your mouse/input between each, in case you need to interact with them. Xorg 1.7+ now supports this!

How else will we get to the upsidedownternet?

https://wiki.archlinux.org/ind...