Изпечатай

[kennedy]

Нищо не разбрах...
защо трябва да се притеснявам от това.
Ползвам сусе от години и чак сега чувам за такива неща 

[growchie]

За десктоп сузе и сървър с големи ресурси не би трябвало да те притеснява.
На мен проблемът ми е, че обичам да си разкарвам всичко излишно, а и ползвам доста слаби по сегашните стандарти машини. systemd ми търкаля зависимости които нямат място на сървър.
Другата бела която ме притеснява е съществуващите ми Gentoo инсталации. (Взех решение да не се мигрирам на тоя етап и ще продължа да си компилирам с -Os и минимални зависимости). systemd не може да буутне ако /usr директорията не е в /, а в отделен дял както е при мен. Проблема се решава като се ползва initrd. Понеже нямам никакво намерение да преформатирам или да си губя времето с initrd (компилирам си сам ядрото на Gentoo и държа да не ползвам initrd) едно евентуално изсипване на systemd върху Gentoo би ми направило системата незареждаща.
systemd не пречи на нормалните потребители и аз ползвах лаптопа си с това близо месец без да знам за какво става въпрос. Повечето съпротива идва от от дистрибуции които поддържат и ядра, различни от линукс. Gentoo има freebsd проект, а дебиан - freebsd и hurd. systemd носи и допълнителната "екстра", че е несъвместима с останалите ядра. Излиза, че дистрибуциите трябва да се откажат от дугите ядра или да държат 2 инит системи, което става кошмар за поддръжка.
Долу горе това е проблема, така че спи спокойно  .

[backinblack]

На мен проблемът ми е, че обичам да си разкарвам всичко излишно, а и ползвам доста слаби по сегашните стандарти машини. systemd ми търкаля зависимости които нямат място на сървър.

Печ, извинявй, не се заяждам, но добре, че разработчиците не се съобразяват с такива като теб!
120-150 лефа струва 1 марков компютър втора употреба с P4 3000 и нагора, с 1ГБ рам и 80ГБ хдд, за 500-1000 лефа има прилични 5 годишни сълвъри, също маркови. Техника която няма проблем с никоя от най-новите дистрибуции. Ти за минимална заплата ли работиш, та ти е толкоз изгодно да се занимаваш с по-архаична и от тази техника!?

[shoshon]

Повечето съпротива идва от от дистрибуции които поддържат и ядра, различни от линукс. Gentoo има freebsd проект, а дебиан - freebsd и hurd. systemd носи и допълнителната "екстра", че е несъвместима с останалите ядра. Излиза, че дистрибуциите трябва да се откажат от дугите ядра или да държат 2 инит системи, което става кошмар за поддръжка.
Долу горе това е проблема, така че спи спокойно  .

Това е много интересно твърдение и с удоволствие бих разучил повече. Имаш ли някакви линкчета?

Защото единственото от man-а, което намерих е:

DESCRIPTION
       systemd-journald is a system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging
       information that is received from the kernel, from user processes via the libc syslog(3) call, from STDOUT/STDERR of system services or via its native API.
       It will implicitly collect numerous meta data fields for each log messages in a secure and unfakeable way. See systemd.journal-fields(7) for more
       information about the collected meta data.

[growchie]

Това е много интересно твърдение и с удоволствие бих разучил повече. Имаш ли някакви линкчета?

Разбира се ведната
За Дебиан: http://lwn.net/Articles/452865/

Undoubtedly Poettering is tired of defending systemd against what he sees as "amazingly badly informed" criticisms. Given that the overall tone of Chroboczek's post was fairly positive, though, it's a little surprising to see the animosity with which Poettering responds. One of the main problems that some in the Debian community (including Chroboczek) have identified with systemd is its "Linux-only" attitude. Poettering addresses that, like he has many times before, but includes a long list of non-POSIX features that systemd uses, concluding: "There's a reason why systemd is more powerful than other init systems: we don't limit ourselves to POSIX, we actually want to give the user/administrator the power that Linux can offer you."

But that power also limits the environments where systemd can run, of course. In addition, the systemd developers have made it clear that they are not interested in taking patches to make it portable to non-Linux systems. In fact, Poettering calls it "practically impossible. about every line of it is non-portable code" in an IRC conversation summary posted to the thread by Matthias Klumpp. All of that makes it difficult for the Debian FreeBSD port, as well as the Hurd effort (and would presumably hinder a humorously suggested Plan 9 version of Debian too).

http://0pointer.de/blog/projects/systemd-update-3.html

Posted by nate at Mon Apr 23 19:21:48 2012
@Antony Williams

Not really. Ubuntu is created by taking a snapshot of Debian unstable and making their Ubuntu-specific desktop changes on top of it.

The closest you can get for Fedora vs Redhat on Debian is 'Debian unstable' vs 'Debian stable'.

The biggest problem is that Debian can't make a decision. They just choose to try to support everything so you end up with 3 different INIT systems.

You have upstart from Ubuntu that Debian tries to support. Then you have SystemD that Debian tries to support. And then you have people fighting to keep the old script-based 'SystemV' style init because that is the only one that can run on the non-Linux Debian versions. (GNU/Hurd and GNU/kfreebsd)

So instead of putting the work into transition to one of newer systems or sticking with the old they just require package maintainers to do 600% more work for 'service up' and 'service down' functionality then any other operating system.

It's just quite insane and a very bad situation for Debian right now, init-wise.

За генту мисля че бях публикувал по-горе линка но все пак понеже дискусията е дълга

http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=262780;page=1;sb=post_latest_reply;so=ASC;mh=25;list=gentoo

http://linux.slashdot.org/story/12/11/16/2052203/gentoo-developers-fork-udev

"After speaking with several other Gentoo developers that share Linus' concerns, I have decided to form a team to fork udev. Our plan is to eliminate the separate /usr requirement from our fork, among other things. We will announce the project later this week."

We already have OpenRC, which has been found to work well on both Gentoo
Linux and Gentoo FreeBSD. The integration of udev into systemd has
caused problems for existing OpenRC systems with people being told that
it is okay to break configurations that users had been told to use over
well over a decade. Many of us consider that to be unacceptable.

И за десерт мнението на мистър Пулс Аудио.

LinuxFr.org : Perhaps Debian will be unable to switch to systemd due to the necessity to support the alternative Debian GNU/kFreeBSD system. What do you think about this situation ? Lennart : Well, it's a loss for them, I guess.
Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that. It's fine if people do toy OSes, everybody loves toys after all. But if Debian thinks it should limit its development by the dreamy interest in toy OSes of some of its developers, then this is their problem. If Debian was my project I'd try to focus on making (or keeping) it professionally relevant, and just forget about kFreeBSD, but I am not a Debian Developer.
That said, I see no reason why it shouldn't be possible to ship some BSD init system on kFreeBSD, and systemd on Debian's Linux version. A package shipping both a systemd unit file and a SysV init script is a workable solution and systemd will handle that just fine.
I think the claim that the need to support kFreeBSD on Debian was a blocker for adopting systemd by default is simply not true

...

И все ревове в подобен стил...

[growchie]

Да не забравяме и Линус Торвалдс
.
https://lkml.org/lkml/2012/10/2/303

From   Linus Torvalds <>
Date   Tue, 2 Oct 2012 09:33:03 -0700
Subject   Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
   

On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
>
> I basically tried a few different approaches, including deferred probe(),
> as you suggested, and request_firmware_async(), as Kay suggested.

Stop this crazy. FIX UDEV ALREADY, DAMMIT.

Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.

"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.

> However, for 3.7 or 3.8, I think that the better is to revert changeset 177bc7dade38b5
> and to stop with udev's insanity of requiring asynchronous firmware load during
> device driver initialization. If udev's developers are not willing to do that,
> we'll likely need to add something at the drivers core to trick udev for it to
> think that the modules got probed before the probe actually happens.

The fact is, udev made new - and insane - rules that are simply
*invalid*. Modern udev is broken, and needs to be fixed.

I don't know where the problem started in udev, but the report I saw
was that udev175 was fine, and udev182 was broken, and would deadlock
if module_init() did a request_firmware(). That kind of nested
behavior is absolutely *required* to work, in order to not cause
idiotic problems for the kernel for no good reason.

What kind of insane udev maintainership do we have? And can we fix it?

Greg, I think you need to step up here too. You were the one who let
udev go. If the new maintainers are causing problems, they need to be
fixed some way.

                Linus

[appmaster]

Ето ви мнението на Линус относно тоя въпрос: Linus Torvalds talking with Aalto University students

[growchie]

Мерси за видеото, това "прясно прясно" от 1 седмица.
"Change for the sake of it" - мисля че много правилно го казва, въпреки че този път си спестява епитети като "lying weasel"

[go_fire]

Новината от днес:

http://www.opennet.ru/opennews/art.shtml?num=35402

[Naka]

За съжаление това се случва с много проекти. В един момент един проект достига зрялост, става почти съвършен, върши си работата идеално и т.н.

Обаче разработчиците му вместо да 'оценят' какво имат и какво са направили почват първо да си човъркат носа, след това почват да си човъркат Гъ**а и се чудят как да го расипят - вместо само да го подържат и да се радват на това което са направили.

Трябва да се симулира някава работа за да може да се каже пред света 'ние работим и измислихме нова технология'!!! А техните шефове и менъджери също са 'заинтересувани' да симулират работа. А пък и акционерите и те ще са доволни че се върши 'някаква работа'.

Та същата работа с systemd. Трябва да го сменим щото бил станал на 30 години. Абе ПМ, щом е работил 30 г. безпроблемно значи всичко му е наред. Променя се нещо което не работи както трябва а не се бара щото вече ми е омръзнало и трябва до го човъркам.

[go_fire]

И като заговорихме тия дни, вижте какво друго  имаме днес:

http://lxer.com/module/newswire/view/176828/