j-g-

I'll just leave this here:

Again, I was perfectly happy not promoting systemd here, actually look around you'll notice the only thread I ever created was the wallpapers one, otherwise have just been responses to others asking about help mostly, It was you and pr1vacy who revived this thread not me.

I would also like to point out that is a shame that the most PR funtoo seems get is because its 'anti-systemd' stance, and even drobbins makes stupid threads just to mock systemd, I think funtoo has more than that and some really neat ideas, I would have liked to try and contribute more (Look at the 2nd most viewed thread in this subforum after the screenshots one, is the one with my wallpapers), but this kind of childish attitude, and some other critisim I won't state here discourages potential contributors, altought it might attract more users 'running away from systemd', and not really trying funtoo because they thought they might like some of the other neat ideas, than just putting effort to block a package from getting installed, wich is what the dev team really does I'd think they would be better and with less work if the policy was just non-solve an redirect to gentoo systemd bugs.

It's open source, and I can do as I like, and have done, actually look at the repo and then judge, I made the effort to make it not invade funtoo suggesting not asking about systemd here and making bug reports about systemd to me, knowing it was just losing poeples time in flames like these. PD: this thread was going dead but you reactivated it actually. If you didn't want to see systemd anymore why bothering reactivating a thread months old?

Speak for yourself, It has got several clones. Even a bug report I have to look into.

My point is that many times the argument made abut systemd doing a lot of stuff , makes it seem as if they just went an shoved every function they could have came up with into PID1, I know it is also an exaggeration but consider somene new to linux who is just trying to informe themseleves about this systemd and init stuff and looking threads and has not much Idea about programming, read these stuff and start to have misconceptions that will only make it harder to really inform themeselves. I have actually looked into what makes the systemd binary singicantly bigger but let's not waste our time any more, I'm sure the both of us have better code to spend it on. Peace.

But I contributed a repo for anyone that wants to try systemd and keep using funtoo, code not just rants, so does your argument stand?(I know it's outdated, but I didn't compromised to keep it working, and actually left a script for automatic sync with the changes to the funto overlay for the curious enough, I also plan to get some time to make the changes to epro to read profiles from overlays, this could not only be useful for systemd, but for other type of profiles), and I wasn't making personal attacks nor implying you were stupid(maybe stubborn), at least it was not my intention I was calling a lie a lie, no matter the person who said it, specifically the arguments "Bootctl is a replacement for grub" its a bootlader no more we have several around not only grub, and "You have to reboot as much as windows" or "Faster boots for more reboots" I'd like to actually put this to test (the longest uptime I can get)with the version of RHEL7, but power outages are quite frequent where I'm right now.

These are the lies or exaggerations whatever you like, I've had that problem with GDM failing, and had no problems finding out how to fix it(emergecy target), and lost no logs at at all, I run fedora on a 32bit mini-hp and gdm doesn't work, so I had to use lightdm, had no trouble changing that using systemd tools. Here another: But systemd isn't a monolithic binary doing everything, And uses several programs in combination to get the job done, and I'd think they were referring to the difference between having a separation of hardware, operating system and tools, to what I've read was the norm back then hardware + specific os or program bundled togheter, the fact that systemd uses IPC and not only stdin and stdout and pipes, is just a difference in the way those programs work together in my opinion, and some of its most popular and useful programs came out out of necessity as well (nspwan). If you actually look at the code main.c(the systemd program PID1, the file that contains it ) Is ~2k lines[1]( I know sysvinit's init.c in the end is smaller and doesn't have as many includes, but the logic of how the init works is still less than 2k lines of code not a big monolithic thing) Look at other init programs lenght counting the files that get compiled and contain the logic for the init: FreeBSD(init.c 1.7K LOC) [2] OpenBSD(init.c 1.5k LOC) [3] sysvinit ( init.c[2.9k] + utmp.c[~250] + init.h [~100] + init_req.h[~100] + paths.h [~100] + set.h [~20]) 3.5k LOC [4] I'd have expected someone of the age you seem in your picture to be more mature, and actually comment something useful, a shame you lose your time making fun of people rather than spreading the wisdom you might indeed have. I wasn't the one ranting about not being able to get logs and just pointing out that you can get even more logs than most want anyway, and I will repeat what has said over and over you CAN get your logs binary or plain Text, you can install another logger the one you have been using maybe?, and the fractions of second of extra latency this adds to logging doesn't really affect any service, and if you want to be real fast for any reason for some service, why logging to something as slow as a hard drive? Anyway, lets not waste anymore time on this, the code is what will speak in the end, these flames will just be space wasted in some server. [1] https://github.com/systemd/systemd/blob/master/src/core/main.c [1] https://github.com/systemd/systemd/blob/master/Makefile.am#L1328 [2] https://svnweb.freebsd.org/base/head/sbin/init/init.c?view=markup [3] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/init/init.c?annotate=1.54 [4] http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/Makefile?view=annotate&root=sysvinit http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/utmp.c?root=sysvinit&view=markup http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init.c?root=sysvinit&view=markup http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init.h?root=sysvinit&view=markup http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init_req.h?root=sysvinit&view=markup http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/paths.h?root=sysvinit&view=markup

You can do the same 'trick' in any linux distro with feh -F , you just need a screenshot in full-screen, and you can fool any regular end user. Don't waste your time in stuff like that, better recommend a easy to use linux distro to that poor windows user.

'I shouldn't need to learn new commands', but you learned the OpenRC commands and those had to be new to you at some point, coming from debian, or a bsd style init like Arch had, and you were asking me to solve a problem you had using my time to read stuff that's available for everyone to read, and of special interest for poeple like you( and me) that deal with computers, and to give you a detailed solution, we are discussing about software here not giving free support. That's why I said it was your problem. I know you do know the commands and in fact are knowledgeable about a lot of stuff I've read some of your post in the forum. I'm just being ralistic here, systemd has come to stay for some years at least in the linux ecosystem, and just buring your head in the sand and wanting pretend it's not there, and having an 'anti-systemd' attitude, will only cost you in your career, I like most of it, I won't defend it as the most clever solution anyone could ever have came up with, but It works, and as all the software has bugs, bugs will exist as long as software and human error exis. Anyway I guess in your case you will actually learn the stuff and rant in formus like this one, longing for the days of 'the true unix' Peace.

adding a 1 to the kernel command line is the way I've done it, I won't read documentation for you when I'm not needing it, It can be done, I know how to read manuals, I can do it, I just don't need to do it often, I have configured my boot process to regularly fsck my drive anyway. The comand to switch to the emergency target would be systemctl isolate emergency.target, again you not wanting to learn systemd, and thus making yourself wrong ideas is not my problem it's yours, I will be able to handle any system that comes my way, you won't because you are reluctant to learn. PD: don't get caught by the nuances of my english, It's not my first language and in fact mostly self-learnt, I also don't like to pretend I know it all.

Starting the services faster is not the goal, it's having a fine grained management resource wise(CPU, memory, IO) of the process and it's child's trough cgroups to ensure, proper start and stop of services, without having to be a shell ninja. The kernel team in fact kind of has gone to the shit, the beloved by many Linus Torlvalds has let Microsoft put stuff like this in the kernel: https://github.com/torvalds/linux/blob/master/drivers/net/hyperv/netvsc_drv.c#L1026 Yes you folks have seen it, the linux kernel restarting an userspace service. Should the kernel do that? NO! Red Hat releases upgrades for the RHEL kernel almost weekly, and the long term kernels at kernel.org recieve security upgrades almost weekly, Hadn't you noticed that?

It can be done, If I'm not wrong, the emergency target is what you would be looking for, about a year a go I asked if you could even do a split of a system that would have everything in one partiotion into /usr and root partitions, WITHOUT a reboot, while running systemd, It can be done, I didn't try it, but got the most knowlegable guy about systemd at the gentoo list(Canek) to give it a try, turns out you can jump back and forth betweeen the systemd you have in the initramfs and your real system, and can change a lot of stuff from the initramfs, an fsck would be easy.

In any modern system facing the internet, not upgrading a kernel weekly is just hoarding kernel bugs to be pwned IMHO, I would prefer to design something reliable that can be resilient if one system fails, so doing a reboot is no problem at any given time. I was talking about my desktop system. In my view, memory constrains won't be an issue in embedded when you get to the 10nm scale, look at CHIP(The 9USD SoC) that thing is pretty small in physical size and you can definitely run systemd with plenty of space to do embedded stuff on it. I'd also argue that a parser for ini-like files, would be much smaller and simpler, than a shell interpreter, so I'd put systemd and --enable-networkd when configuring the compilation, I in fact quite like the idea of a shellless system depending on what it's doing, exploits that run /bin/sh after breaking a arbitrary code execution vulnerability, it would be pointless, and would just end up in a crash.

Gentoo uses git now too so that isn't something in favor of Funtoo anymore. In my desktop with Gentoo I have this now for getting the portage tree: [DEFAULT] main-repo = gentoo [gentoo] location = /var/lib/portage/repos/gentoo sync-type = git sync-uri = https://github.com/gentoo-mirror/gentoo auto-sync = true The main thing I like about Funtoo is the profile system.

And I disagree, It goes both ways, on the gentoo list I've seen some folks, move to systemd, the thing is the systemd detractors tend to be more vocal about it(I find most to be people with too much time to waste) I'm in fact one of the people who got a bad taste of systemd in the first try, back when I was on Arch, it made me go to debian, and then I came to Gentoo and Funtoo(wiht a bit of BSDs in between that), and at some point decided to give systemd a try without the prejudices that you hear all the time, and now I quite like how pratical it is, and how easier it makes installing gentoo, and systemd-nspwan is one of my favorite things ever It's been more than 1 year now I haven't run chroot.

It would be kind of stupid to use ifconfig and a script considering there's systemd-networkd(and ifconfig is unmaintained, I prefer iproute2) , and you could set up a proper unit for static networking, using something simple like this: /etc/systemd/newtork/50-static-eth0.network [Match] Name=eth0 [Network] Address=192.168.12.200/24 Gateway=192.168.12.1 But I don't know of anything that would prevent something like this from working: [Unit] Description=Lazy net config [Service] Type=oneshot ExecStart=/sbin/ifconfig eth0 192.168.12.200 [Install] WantedBy=network.target Don't like that and would prefer emulating something like rc.local : [Unit] Description=Local Service [Service] Type=oneshot ExecStart=/bin/sh /etc/rc.local [Install] WantedBy=multi-user.target It's going against the point of having unit files, but it can work. Also bootctl is more like a modern lilo for EFI, that a grub replacement and the configuration is quite simpler than grub. BTW: I see you as kind of a unix purits, so here's a video from one of the men who was there when unix was born(Prof. Kernighan), about pipes and some programming stuff. When unix started, It was not so much about 'one program, one thing', as the design goal, but more about memory constrains. Another lie is saying you have to reboot for everything like in windows, apart from being a cheap argument because, the reason is mostly about kernel drivers, wich has nothing to do with systemd., I only reboot when I install a new kernel, if I get updates from systemd, for most stuff systemctl daemon-reload works well if even needed. I get uptimes of ~2-3 weeks regularly if I don't have power outages. PD: The binary logs argument against systemd isn't valid anymore, most livecds and distros have journalctl, and most distros put it in the initramfs also, you yourself said it(systemd is everywhere, isn't it?), and I don't know you but I still can't read and decode bits from the inside of the plate of my hard drive into UTF-8 characters telepathically and have a mental grep to search trough it, You need something that decodes your logs from the BINARY that's on your hard drive anyway, you need a program to read logs, that's my point, so you CAN read your logs, In fact you can read much more information about failures, and filter it more quickly to get the lines you care about, than what you had by simple text files in /var/log/, If YOU can't do it only shows you can't or don't want to read manuals nor search the web. Can you get logs of early boot as this using a traditional grub+sysvinit boot? oct 18 10:42:03 localhost kernel: Initializing cgroup subsys cpuset oct 18 10:42:03 localhost kernel: Initializing cgroup subsys cpu oct 18 10:42:03 localhost kernel: Initializing cgroup subsys cpuacct oct 18 10:42:03 localhost kernel: Linux version 4.2.3-gentoo-gentoo-kdbus (root@jdesk) (gcc version 4.9.3 (Gentoo 4.9.3 p1.2, pie-0.6.3) ) #1 SMP PREEMPT Sun Oct 18 03:14:18 CST 2015 oct 18 10:42:03 localhost kernel: Command line: initrd=\initramfs-4.2.3-gentoo-gentoo-kdbus.img root=LABEL=gentoo rootflags=subvol=gentoo-root ro oct 18 10:42:03 localhost kernel: x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100 oct 18 10:42:03 localhost kernel: x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers' oct 18 10:42:03 localhost kernel: x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' oct 18 10:42:03 localhost kernel: x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' oct 18 10:42:03 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 0x340 bytes, using 'standard' format. oct 18 10:42:03 localhost kernel: x86/fpu: Using 'eager' FPU context switches. oct 18 10:42:03 localhost kernel: e820: BIOS-provided physical RAM map: oct 18 10:42:03 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable

Did you look at the quote date? , 7+ months should have been enough for OP to take a decision, when you revived this thread, I think most took it as if you just wanted to talk about minimal desktops, and then the thread got deviated into a discussion about features.

You can have all those things you say, I have applications menu, places menu, and you can have a window list at the bottom(very much like gnome2), when not having a touchscreen these are useful, can be activated using gnome-tweak-tool under extensions, and 'Dash to Dock'[1] a very nice dock extension is available on the gnome extensions site, it's really configurable, for me it simulates a hidden windows list on the right, I would say it is the best extension I've seen, I really think it should be upstreamed and included as a default, it adds a lot(mainly in a regular desktop), as it doesn't change the way gnome currently works and brings the best of the apple dock and the windows task bar. [1] https://micheleg.github.io/dash-to-dock/

Oh sure there is, the windows key(or mouse up left corner) and the way it works, is completely its own thing in combination of what you type after. it's more than just a nice way of seeing your windows. I also like minimalistic windows managers and always keep awesome around, Sometimes I just need tmux and firefox tiled, but really gnome has got really better than what the initial version 3 was, so I only log into awesome when I'm using various vms( I don't have tons of RAM). +1 The way gnome designed the use of the Mod4 key is indeed really good, You can even throw math at it! type Mod4+'2+2', I bet that you couldn't do that with openbox, unless you write some code.

You can create a chroot on a computer that has internet, and configure it as if it were the ofline system, and use binary packages built in the chroot, only try to keep the cpu options generic at first(you can tweak as you go later), you can then build there and only install the binary packages on the offiline system. You only need to set PKGDIR, PORTDIR, DISTDIR in make.conf, and use a flash drive mounted in e.g. /media/funtoo/ containing a copy of your world file and the the directories {packages,portage,distfiles,config}, set the variables pointing to these, the same on the chroot as the offilne system, create a git repo of /etc/portage/ and commit every change you need to make to the files inside there, this is the 'config' directory inside /media/funtoo, and git push and pull using that directory. Alternatively, you can setup a simple lan with a network cable or via ad-hoc wifi, and use the guide for binary packages. The key is to have a portage snapshot, a valid configuration (/etc/portage), and the set of packages built for that configuration, this way you can make portage resolve the same build in the chroot as the off-line system. As the target system is off-line, you can upgrade it every 1~2 months, as it is an off-line system you don't have to worry much about security. the manuals make.conf(5) and portage(5) have more info on the details.

So you weren't paying attention to the partitions you created, good way to follow the installation manual.

It is not on the tree, but the upstream git page has instructions for installation in gentoo(you can apply those to funtoo) from a greek overlay, but you'll need to learn about layman and overlays (non official repos), package.accept_keywords and live ebuilds(versions 9999* basically fresh from git). start by installing layman also you should check eix(emerge eix) to search for packages, nobody really uses emerge --search(too slow). If you will try to install it, I advice you, when using overlays, be aware the quality of the ebuilds might not be as good as the main repo, the ebuilds might be unmaintained. But that shouldn't stop you, just check the overlay is being maintained, and if you use live ebuilds, that means you can report any problem you have directly to upstream because you are building their latest code.

https://android.googlesource.com search for platform/prebuilts/gcc/linux-x86*, I think you could just unpack it to something like ~/opt/ and change the environment variables accordingly, would do the work, but crafting an ebuild that neatly downloads this an unpacks it to /opt, and adds the paths to /etc/profile.d/, isn't complicated to make either, and you get to have something you could reuse later. I don't know if it would fit what you are doing, but there's an app called Terminal IDE[1] on google play, that comes with gcc(though old 4.4), ssh(server, or was telnet I don't remember) , vim and tmux. and it's a few taps away. [1]https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside

Why converting package.mask to a directory seems so confusing? just stick the file you have now with a different name inside the new directory. But the fastest way is to use the android provide binaries by android, I'm assuming you have an android phone, install the android-sdk-update-manager, add yourself to the android group, launch it and select the 'SDK Platform' for the version you are using and install it, it will install a crosscompiler for arm, and this will end up in your PATH: /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin /opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin /opt/android-ndk/toolchains/mipsel-linux-android-4.9/prebuilt/linux-x86_64/bin