nrc
-
Posts
94 -
Joined
-
Last visited
-
Days Won
19
Content Type
Profiles
Forums
Blogs
Posts posted by nrc
-
-
Ah. That's a consideration that I did not make. Rookie mistake, I guess. I still think it's interesting to see what everyone else is doing. How's SteamOS by the way?
SteamOS does what it's supposed to do in providing a reliable platform for games. There's really nothing special about it other than the fact that it boots straight into Valve's console-style interface. I keep it around for times like now where something in my Funtoo install is causing games to run slow.
-
My latest machine is an Alienware Steam Machine (nee Alienware Alpha). I wanted to maintain a clean copy of SteamOS to see how it would develop so for my normal desktop use I added a USB3 SSD and installed Funtoo to dual boot.
Intel Core i7-4785T CPU @ 2.20GHz
8GB
GeForce GTX 860M
The problem with comparing compile times is that there are thousands of different variables in there. Kernel versions and options will differ and emerge commands pull in completely different collections depending on your install.
-
The nfsmount startup from nfs-utils is deprecated. Make sure that you have the netmount startup configured.
-
Welcome. Amost two years here and wish I'd made the switch sooner. Stuff just works.
-
deleted. Above sounds likely.
-
Is this a script created for openrc or a regular bash script? I believe openrc expects the former and it may ignore anything that doesn't have #!/sbin/runscript or #!/sbin/openrc-run as the first line.
-
When you manually start vboxdrv are you doing it with the init script? Any errors?
/etc/init.d/vboxdrv start
What do you get when use the eselect rc module to start it?
eselect rc start vboxdrv
Do you have rc logging enabled in /etc/rc.conf? Any errors in the log file?
-
I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.
Unfortunately a lot of people have bought into the misinformation that you can't have a modern Linux distro without systemd. Spread the word. http://without-systemd.org/
-
There would seem to an issue with fragmentation of our userbase. This will only get worse. It would be nice to abstract daemon installation in some portable way.
Maybe some application that could convert from some universal configuration to whatever the local init system requires, or perhaps we should accept that systemd will be prevalent and make a converter that converts systemd configurations to openrc scripts? Does such a think already exist?
More about me at https://eddon.systems
It seems like it would be pretty easy to write a generic init script that would use unit files like configuration files. Call it unitrc. Then making a unit file work for start up would just be:
ln -s /etc/init.d/unitrc /etc/init.d/myservice mv /usr/lib/systemd/system/myservice.service /etc/conf.d/myservice rc-update add myservice
Note that systemd's service startup information is stored in /usr. Another example of the perversity of systemd.
-
Nope, I am pointing out that I don't have a choice about my init system and that the lack of this choice, in particular, will aliniate any user that doesn't participate. You should, at least, have a choice of, what today, is becoming the industry standard init system, resource manager, loging solution and booting-watch-cha-ma-call-it. That's all.
As uudruid74 pointed out earlier in the thread, Funtoo doesn't exist to provide you with the "industry standard" anything. If that alienates someone then Funtoo isn't the right distribution for them anyway.
To quote the Wiki: "Funtoo Linux is a project of people who agree with the philosophy of the ideal tool, and who are passionate in our desire to improve technology to be as close to this ideal as possible." That's the purpose of Funtoo - for the BDFL and like-minded individuals to pursue the ideal tool in each instance and share the results with those of similar mindset.
"The ideal tool" is similar to the "small, sharp tools" that are the core of the UNIX philosophy. Not only does systemd run counter to that philosophy as an init system but it also pre-empts attempts to create "the ideal tool" in many of the technologies that have fallen prey to its all-consuming hunger to control every aspect of your system. Elegant tools like boot-update and Funtoo's core networking templates would be rendered moot by systemd imposed kludges.
Simply put, systemd is contradictory to the core principle of Funtoo. Funtoo with systemd wouldn't be Funtoo.
Well, you speak of things like if they happened unilaterally. Developers at work made their decisions and came up with, what they thought, it was the best plan. The result of SystemD taking over stuff is just a consequence of devs thinking it is the best option. I am happy to trust them on that.
All those choices weren't based on merit. Some distributions chose systemd because they had little other choice. Redhat controls many of the projects they rely on and they felt that they didn't have the resources to create replacements or deal with all the incompatibilities that Poettering was creating.
Fortunately the smaller distributions that have declined to adopt systemd have made better progress at working around those issues than some thought would be possible at this stage.
Yes, I know. I do trust him and I am not pointing a gun at anybody. I am just expressing my opinion; as you are. I truly think that Funtoo should allow and support SystemD; while favoring whatever Funtoo likes. That's all. It will be easier and people that hate it can still say they hate it. Win <-> win, huh? ;)
The opinion that you're expressing contradicts the Funtoo vision. If you want systemd you don't understand that vision and you're using the wrong distribution.
-
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:
No, they're just other people's opinions and experiences. The fact that they're different than yours doesn't disprove them.
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).
Systemd is exactly what Kernighan and Pike referred to as a "monolithic self-sufficient subsystem." It's a collection of tightly coupled binaries, each of which does more than any single program intended for its purpose should in a UNIX-like environment.
It has nothing to do with hardware and OS bundling. We're talking about the UNIX philosophy - portability across hardware was a key attribute from day one. They were specifically talking about what programs do and how they interoperate.
Your comments suggest that you're not familiar with the UNIX philosophy. Wikipedia has an entry that is a good starting place to learn more about it.
https://en.wikipedia.org/wiki/Unix_philosophy
You're free to think that the UNIX philosophy isn't really important today. I believe that it was a key factor that enabled much of what we enjoy in the open source world today and that's important to maintaining those benefits in the future.
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]
Your numbers here are nonsense. The systemd main function pulls in tens of thousands of lines of code from other source files. Do you really believe that 2k of code compiles into a 1.5MB executable for systemd but 40KB for sysvint? We're talking about a binary that is forty times larger.
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.
A person of the age that I seem in my picture recognizes that when someone says something ridiculous sometimes it's better to laugh at it than bother to argue with it.
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.
I don't care if you like systemd. Feel free to use a distribution that supports systemd. You can sing its praises in the forums for those distros to your heart's content and you will never find me there arguing with you.
I believe that systemd and the mindset that spawned it is harmful to Linux and open source in general. I believe that it's important that we continue to have distributions that are dedicated to working without it. For that reason I support Funtoo and I will argue against anyone who comes here and claims that systemd is a good thing or that Funtoo should support it.
-
I'd recommend focusing on getting portage updated. Portage is python so look at the slot conflicts related to python.
It looks like dev-python/pygments and dev-python/numpy may be your problem.
Try updating these to get them past the version creating the slot conflict:
emerge -auv dev-python/pygments dev-python/numpy
If that's successful you can proceed with the portage update. If not you might try removing them temporarily. I cleared a similar conflict with dev-python/numpy that way when updating portage.
-
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.
You don't seem to understand what Kernighan is saying. It's true that memory constraints played a roll in the creation of early UNIX tools but as Kernighan says in the interview, "Necessity is the mother of invention." That invention - the UNIX philosophy of small tools interacting with one another - continued on its own merit for decades after memory constraints ceased to be a consideration.
As Kernighan and Pike wrote in 1984, "[The UNIX] style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs."
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.,
You never established that anyone was lying about anything. It's rude to claim that someone is lying just because you don't understand or agree with their point of view.
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.
Binary log files are not acceptable. Using a binary format renders them susceptible to corruption and creates a source of problems and incompatibility among tools.
Text log files don't require any special tools. I can use essentially the same tools to examine logs on any system going back to my first UNIX system from 1984. I don't need to worry about whether my rescue thumb drive has the right version of some specialized utility on it.
Every excuse for adopting binary logs could have been addressed with proper configuration of existing tools and development of user space tools that met the specific needs that were unmet.
Your comment about reading manuals is specious. The fact that many here switched to Funtoo from other distros proves that this has everything to do with philosophical objections to systemd and nothing to do with unwillingness to inability to learn something new.
Can you get logs of early boot as this using a traditional grub+sysvinit boot?
-
Systemd has tentacles moving in every direction in Linux. At this rapid rate of growth and the attitude of Poettering and friends it seems obvious to me that they are attempting a coup d'?tat starting with change requests to the kernel.
I think Poettering already put his toe in the water on this last year with his rant about how mean the Linux Kernel maintainer's list is. Either he didn't get a sympathetic enough response or he's waiting because he's already got enough on his plate.
I have to say that I'm pleased with the way the contra-systemd Linux world has developed in the past year. A year ago Poettering seemed quiet confident that he had built a dependency trap that would make distributions without systemd undesirable if not completely impractical. For a while it seemed questionable whether the contra-systemd community would have enough critical mass to tackle some of the more sticky problems that he was creating.
Fortunately the developer community has already come through and solved many of those problems and a sustainable ecosystem of alternative solutions appears to have developed. Ultimately I think this is a good thing. Even as a long time Redhat user it's clear to me that the commercial distros have gained too much weight in pushing the development of Linux to suit their agenda. It was time to take Linux back from them and it feels like we have the beginnings of that.
-
Here is another page that describes the unfork process in a bit more detail.
http://www.funtoo.org/News:Project_Unfork_Status
Quoting:
Over the years, we've accumulated a lot of forked ebuilds, and while that gives us more control over the upstream ebuilds, it comes with a maintenance cost. Since the ebuilds are now forked, they now need to be maintained. And since our team is extremely small (1-3 people,) over time, these ebuilds go out of date. In addition to about 250 ebuilds forked in funtoo-overlay, we have integrated the Progress overlay, consisting of hundreds of python ebuilds, as well as forked pretty much the entirety of GNOME (about 200 ebuilds).
If forking were the only option we had available to ensure that ebuilds built reliably, then I'd keep forking ebuilds. But fortunately, there is a new option available, and that is by using a method I created using a thing called 'shards'. The benefit of 'shards' is that they will allow Funtoo to provide consistent results to users without relying on the maintenance-intensive practice of forking Gentoo ebuilds. This, in turn, will also help us to collaborate more closely with Gentoo, and to focus on things that make a difference, rather than duplicating work.
What are shards and how do they work? A shard is a set of related ebuilds from Gentoo, such as 'all the GNOME ebuilds', 'all the python ebuilds', or 'all the perl ebuilds'. My merge script grabs the latest changes to these sets of ebuilds and stores them in a git tree. Now, in the past, we have imported Gentoo changes automatically every few hours, except for ebuilds we have forked which change a lot less often. With shards, I can freeze the version of a specific set of Gentoo ebuilds to a particular point in time. This provides a consistent and known-good set of ebuilds to Funtoo users. Before bumping to an updated revision of the shard, Funtoo can now proactively perform quality assurance testing to do our best to make sure that any updates will not cause problems for our users. This way, we can proactively test rather than respond reactively to problems after they have arisen. This is much more time-efficient and provides a better experience for our users.
-
For those like me who don't regularly check the news pages it's worth noting that the unfork tree is live. Good stuff ultimately but you may have some pain in updates until everything is sorted out.
-
The boot.conf man page lists recognized values for the type variable. Right now win10 is not listed. I would suggest using win8 and if that doesn't work file a bug.
The type variable should be set to one of the operating system names that boot-update recognizes (case-insensitive,) which are:
? linux (default)
? dos
? msdos
? Windows 2000
? win2000
? Windows XP
? winxp
? Windows Vista
? vista
? Windows 7
? win7
? Windows 8
? win8
? Haiku
? Haiku OS
-
If you have an extra partition or drive just install Funtoo there and use mounts and/or sym links to get to what you need in the old installation. That's what I did to transistion from Fedora. -
Thanks. That was working at one point and then quit and I never got around to figuring out why. Something else must have been pulling in libedit before.
-
I came straight to Funtoo so I can't speak from experience on Gentoo but I know that I like some of the things that are frequently noted as differences.
The profile system makes it easy to create a build that is very specific to your needs.
The git based portage system is fast and efficient.
The network configuration tools seem simple, logical, and effective for me as UNIX/Linux old timer.
The boot-update tool gives me control of my boot process without the pain of dealing directly with grub2.
I believe it's important to pursue alternatives to systemd and Funtoo does not support systemd.
-
This is only my opinion and, since we coexist in a free and friendly community, I think this is the right place to post this.
Ditto.
Systemd has been adopted by many of the important GNU & Linux distributions all around. It is the standard in all the new main stream distributions; or, at least, most of them. This is not because they're all blockheads and made the decision to switch just for the sake of fashion. Then again, I have not read the code and am not aware of the specifics.
It is used a lot and it will be the industry standard for servers and embedded systems.
No, they are not all blockheads. That doesn't mean that they're making the right choice. Redhat is happy to have their employees setting the Linux ecosystem on a path which they dictate because they can fund the resources to make it happen. So they have people in all the major projects creating interdependencies which Poettering has boasted will make it impractical for distros to use anything but systemd.
Many distributions have gone along simply because they don't have the resources to fix everything that Poettering has broken and will continue to break as he slowly consumes the entire system and user space. Others actually are blockheads and simply don't understand that what they're doing is ultimately bad for Linux and the open source world.
We do not use it. We consider it trash. We, also, alienate ourselves from the rest of the industry and become something totally different; which makes it really hard to be considered as a serious alternative OS for the aforementioned. One can, always, implement it as far as one can and use it wherever it is possible. It's, still, hard to convince my manager/client that Funtoo is awesome, though.
If Linus hadn't alienated himself from the rest of the industry back when he decided to do his own kernel we wouldn't have Linux today. This is how open source becomes stronger. People with ideas are free to find better ways to do things. systemd cuts a growing swath through the Linux ecosystem where nobody else is allowed to have a better idea because they're tightly coupling all the pieces they control together and they won't play nice with anyone.
Most of the world doesn't use rolling release source distributions either. You're saying you can convince your manager/client that's the right choice but choosing openrc over systemd is a problem?
Systemd is not bad at all. I've used it since I come from Fedora. To me, it is really simple to use, well documented and easy to understand. It manages almost every aspect of the system; and keeps growing since almost every upstream project is using it and contributing to it. It is destined to become better.
I used it before I switched from Fedora also. We have a fundamental difference of opinion because the things you seem to think are good are actually very bad in my view. It continues growing, I'll give you that. But not in a good way.
Meanwhile, we cannot even use it since it is not supported. This choice is not given to us. One has to go against our distro in order to try it out or test it's implementation. The alternative is to switch to Gentoo; but I didn't come to Funtoo to start using Gentoo.
You already noted that most distributions are using systemd. Those systems by in large don't give the choice of replacing systemd with openrc. Fedora had a choice and they made it. Funtoo had a choice and they made it. Each distro is directing effort where they feel that it will most benefit their goals.
I believe strongly that Linux should not become a homogeneous ecosystem where everyone is forced into a single choice dictated by the strongest players. I appreciate the fact that Funtoo has decided not to go along with those who think that's the right direction for Linux.
I'm happy that Funtoo has chosen to focus on making things work without systemd and I hope that they'll continue that focus.
-
Funtoo uses a forked version of openrc because some of its unique features - networking configuration in particular - are tied into the rc scripts. Getting the gentoo version working would probably require quite a lot of work.
If there's a feature in the newer version that you need you should probably open an issue in the bug tracking system.
-
Yes, you need to tune your kernel configuration. I run debian-sources and I've got a little over 60 modules loaded.
-
// , Putting on my skepticals, here:
Does Funtoo put users first in a broader way than convenience?
If Funtoo really puts users first from a long term, ethical point of view, why isn't it FOSS?
GNU and the the Free Software Foundation have nothing to do with putting users first. They are idealogical organizations who expect users to sacrifice their own interests to further their agenda.
Thanks, Funtoo!
in General Discussion
Posted
It's been pretty quiet lately so I want to throw in another "thank you" to the crew that creates and maintains Funtoo. I discovered Funtoo as a way to fight systemd but I've been really pleased at what a great all-around distro it's proven to be. So, "Thanks!"
Obligatory systemd hate: http://suckless.org/sucks/systemd