oh, i/o error commented?
Gentoo comes with OpenRC instead of systemd. It is also a perpetual LTS version, since you never dist-upgrade or any other shit, it just keeps rolling.
And if you need to compile a few things from source anyway, you can wrap them up in an ebuild and let it build for you without worrying.
Sounds like Kali 2.0 Linux. Rolling updates... nice when you want to be practical, difficult if you want people to teach others how to work with you.
I keep hearing good things about Kali from people who new to Linux and only slightly interested in it. What's the deal with that? What makes Kali different other than rolling updates?
It is a security focused distro, usable for pentesting and stuff like that. Says wiki:
I haven't really used it, but I am planning to put it on a usb pendrive to carry around.
Does anyone here have an HP network all-in-one with a memory card? If so how do you access the memory card from Linux? The setup I used in my Ubuntu 12.4 install is now obsolete, the software package is no longer available.
When I use this thing called "google" it brings up the no longer valid link or a suggestion about using "connect to Server" with windows share but I can't find information on what username/password to use to connect to the all-in-one. There is an admin password for the all-in-one that doesn't work. My samba username/password does not work.
Thu Jun 16 2016 13:15:28 EDT from Sig @ UncensoredMy little Pine64 single board computer... but... uptime.
If there's anything those single board computers are good for, it's uptime. My Seagate Dockstar (basically a neutered SheevaPlug) ran for 860 days until I decided I needed to upgrade the aging 2.6.32 kernel. Could have easily broken 1400 days uptime if I didn't shut down the system to move it onto a cart.
This is a bit of a tough one. My Google-Fu is usually pretty good in this regards but not for this specific case.
A short while ago it was announced that if you were using Skylake processors, that the Linux power management is/was utter garbage and you'd best avoid Linux until the issues were fixed. Intel later released a statement that if your system cannot go into the newer power states, premature failure may occur for those using Skylake (and similar) SOCs and CPUs.
I've experienced this issue firsthand with Bay Trail, my Atom Quadcore netbook would randomly freeze during light load situations... Traced the issue down to cstate switching. I had to set it to a Max CState of 2 in grub/kernel before I could use the system without random freezes. The worst result is that you had an older processor power-wise: Speedstepping, but no voltage dropping and idle/off states that would further reduce power.
Turns out that Skylake takes it a step further and depends on these lower states to preserve processor integrity. (Seems fishy to me as aren't CPUs supposed to be able to run at full load when needed?) I got a nice laptop for work use and wanted to put xUbuntu on it. There's some guides out there that cover my model specifically... to be able to fully tweak it for Linux (it's largely compatible as-is) but NOTHING about the cstate issues. I search, I find bug report threads... but nothing that tells me one thing:
How will I know when it's safe to install any Linux kernel for the proc? Seems we hear a lot about the problem but not when it's resolved. If it gets resolved. Or at least, have confirmation that using Linux isn't going to cause potential issues with hardware down the line (and man, that sounds like Microsoft FUD... Keep windows on your machine or IT DIES!)
Windows 10 blows.
This will surely be fixed by the time Skylake-E comes out and the datacenter crowd can't live without a functioning Linux on that chip.
Re: Kali Linux...
Yeah, specifically, the current version of it is derived from Debian's "Jessie" release. It's used in cyber security to perform penetration testing. But I've heard some people suggest that it's kind of a beginner's tool for such efforts, and when you grow a little more in your testing, you might create your own machine or significantly alter Kali as desired.
Heh. I'm a beginner, hands down. I'd need training even to use Kali, although it does come preloaded with a lot of commonly used tools.
I forget why I mentioned it. Oh, something about rolling releases... they elected to go with that model for updates. Just like Windows 10. Heh.
(Now I feel like a troll).
And so, the comparison to Windows holds up?
Actually, truth be told, I'm coming to hate linux as I hate windows.
It's a different set of problems, but boy-howdy does linux give me headaches sometimes.
I have to be able to support linux machines that are 10 years old (which is already ridiculous, but I fully understand why we have this need). And because we're closed-source, we have to build these things and provide installers and setups.
Windows is nice and simple if you want to have a service. You just conform to the SCM and everything works nicely.
But linux? Daemonization is only the first (and easiest) hurdle to cross.
After that, you have to figure out what kind of init script... are they using systemd, upstart, or the traditional sysv init scripts? Yeah, maybe you can extend a middle finger and just do sysv init scripts for everything, but you miss out on the features the other methods provide.
Oh, and if you're installing on an older Kali box, you have to fiddle with upstart-rc.d a little bit to make it so your service will start when the machine comes up. Unless you want to do what that script does manually in your debian postinst file.
I just want to get stuff done, and I'd like as few surprises as possible while trying to make that happen. Both oses provide lots of surprises.
The problem, of course, is that you can't (yet) count on systemd being everywhere.
Upstart sucks and is going away, so we can disregard that.
I have to rewrite my install routines soon, and I'm thinking about abandoning sysv-init scripts altogether. If systemd is detected, we go with that; otherwise we put an entry directly into /etc/inittab. In both cases, the program runs in non-forking mode, and can restart automatically if it crashes.
I'd love to disregard upstart, but sadly, I can't. Or, at least, I shouldn't, if I want this tool to work and play nicely on older ubuntu machines.
Ugh. Having to support old machines suck.
I also can't drop sysv scripts, much as I wish to, for the same reason.
So, I have a funny postinst script that detects which flavor of init the machine uses, and installs the appropriate script (with, in systemd's case, slight modifications to the file because systemd doesn't pass environment variables, so I have to set them explicitely).
released a statement that if your system cannot go into the newer
power states, premature failure may occur for those using Skylake
(and similar) SOCs and CPUs.
I caught wind of this article again, while researching some flakiness on a *Haswell* *Windows* box.
I think the system damage concern may be limited to Skylake notebook. There's a lot more thermal headroom on a desktop.
Look, C6/C7 states are hard to implement. They shut down the whole CPU package and disable PCI-E cache coherence snoops. Every driver for every PCI-E device on your system must cooperate with the whole song and dance, and it's not going to be possible to enter C7 on a system with discrete graphics.
My Windows 10 box was regularly blowing up (hard freezes) after I tried enabling C6/7 in the BIOS. This problem is by no means limited to Linux.
For example: I suspect every SATA controller on your system must agree to enter Link-Power-Management state when your CPU goes C[17~6 or 7.
That's what I've heard though, and in practice the people crowing the
most about Kali seem to be "not Linux people" who are just happy to
have a pre-built set of tools for them in one place so they don't have
to "become Linux people" to perform pen testing. And that's ok, I
But these are not people who are competent to perform pen testing. Wow.
Heh... one starts somewhere.