While phones (Jolla) running wayland have been on the market for about a year.
I am concerned about more practical side which is to administer the servers at my responsibility *without* using systemd altogether - I do not use graphical interfaces, but it appears that after Jessie, there wont be alternatives.
Have you actually tried using a distribution that has fully migrated to systemd? What exact problems did you run into that would prevent you from administering your servers? Did you notice that it specifically has features for servers? Did you notice any conveniences (e.g. 'systemctl status foo' showing you the last few log entries from foo)? Did you notice your crappy init scripts (as long as they had LSB headers) still worked?
You also seem to imply that systemd requires a graphical interface
Similar logic applies to having the ISP cut off your connection entirely -- if they got statutory authority for one of them, I bet they could get the same kind of permission for the other (if the original language of the law doesn't cover both already).
I am not sure how it works in the U.S., but for example in South Africa, retail internet access products are usually provided subject to Terms of Service, which would allow for remedial action of some kind for abuses such as spamming, port-scanning etc.
Next up: Booting all of your connectivity -- mobile as well as hardline -- through one, integrated, Big Brother-ish app.
You say that as if there isn't a billion-dollar broadband policy (PCRF) and control (PCEF/"DPI") market
And the best way tools such as this have to communicate updates to those who shoupd get the updates is
Surely there are other mechanisms to keep people stress-free while on leave? I just turn off email synching until the morning I return to work (with a suitable OoO message set).
On Android, access to the contents of the device requires the screen to be unlocked. Does iOS also require this?
(Access to the device without installing drivers isn't an issue, but the computer OS should prompt before automatically mounting the device too, which I believe Linux does but Windows doesn't).
It'swould be more like Cisco requiring ypu to buy a software/feature licence to use 10Gbps ports on hardware you already paid for.
Oh wait, they do that already (e.g. on ASA-5585-X, probably other ASA nodels too)
1) You can use a different logger with systemd
2)To watch log messages with journal, journalctl -f
There are still some things I don't like about the journal (I haven't seen how to specify different retention rules for logs of different applications), but then I've only spent a few minutes actively using it.
Maybe the thing that irritates me about journal is I don't know what previously unsolved problem it is trying to solve, while making some log processing difficult.
But, if you are booting from CDs, and the CD has the rest of the media, why do you need the utility for verifying signatures on the boot media (1.44MB image)? Bootstrap the installation image from the iso9660 part of the CD (or network in the case if a network install)? and have that contain the signature verification utility.
Hint: RPM-baswd distro have been doing this since rpm 3.x, or about 1999.
Really, who uses floppies for installation these days? Sure, maybe floppy emulation on a DRAC or iLO or ILOM, but they all
-support CDROM or DVD emulation
-PXE boot (with relatively large images possible via TFTP)
If none of these are options, just write the whole (hybrid) ISO image to a 4GB USB flash disk and be done with it.
I personally haven't used an actual CD-RW or DVD to install a syatem in about 5 years. Either network install booted via PXE for servers, or USB flash disk for laptops.
I am on Android, and I don't see any way to see the video from m.slashdot.org.
Oh, and that still doesn't answer why laptops are trickier than desktops in this regard.
Unless your boot is "Please enter password to boot up computer" before it can boot the OS.
Of course it is. Any other FDE is the sprinkling of magic encryption dust kind of FDE. Both initscripts (on RH-style systems) and systemd support this, and have for years.
c) full-disk encryption can be tricky to do right on laptops, which are the main user of WiFi.
I have been using full (or, full enough,
I have used KDE for a long time. My laptop has an embedded 3G card that works better / more easily with NetworkManager/ModemManager than with more traditional (e.g. pppd, wvdial etc.) setups. Thus, I tried KNetworkManager.
However, I use WiFi networks with both WPA2 Personal, and WPA2 Enterprise, security. I don't mind my WiFi keys for the WPA2 Personal networks being stored somewhere, but I don't want my passwords for WPA2 Enterprise networks stored *anywhere*. Before trying NetworkManager/KNetworkManager, I would have all the WiFi configuration in
However, with KNetworkManager, my options are:
In the 'Store' case, due to my KDE Wallet settings (including 'close when screensaver starts'), now every time I resume my laptop, I will be prompted to enter my KDE wallet password (longer/more complex than the WPA Enterprise password).
In the 'Always Ask' case, I am required to enter my password *every* *time* I associate to the the SSID.
So, maybe it is better than nm-applet (I haven't used nm-applet *that* much) or the Gnome 3 integration (which I only see when trying to help a colleague), but it most definitely isn't better than the old
At present, I don't care about having a WiFi network connected before a user is logged in. Surely on a typical laptop, that occurs once a month or so? We have network authentication with cached crendentials, and I can kinit after logging in anyway. If this is really a requirement, using TPM (with all of its failings) would probably be a better approach.
I thought this was a tech site.
Surely one of the obvious answers options should be for someone who implements the rules to ensure that bandwidth hungry users don't kill the experience for all the others (as evidenced by other answer options and numerous comments).
Remember that to make a service affordable (while ensuring some kind of return on investment) all consumer internet access networks are designed with contention ratios. Managing users who try and get as much as possible is an obvious requirement if you don't want all users to have a crappy experience
And all platforms that support EAP support PEAP with MSCHAPv2.
Any network that does PEAP with MSCHAPv2 using credentials thay are usee dor any other service is vulnerable, unless the clients will require certificates signed by a trusted CS cert.
Android authenticating via FreeRADIUS to Samba password hashes to allow access to an AP running OpenWRY would be vulnerable by default.