Na uporczywych dłużników Wspólnota Mieszkaniowa ma dosyć drastyczne rozwiązanie. Na podstawie art. 16 UoWL można sprzedać mieszkanie takiego delikwenta i z przychodu pokryć dług. Opcja ma taki kaliber, że nawet Trybunał Konstytucyjny ją rozpatrywał. I uznał, że jest zgodna z Konstytucją.

Przy okazji jednak pojawiła się informacja, że trwają prace nad nowelizacją wspomnianej Ustawy. W sposób zakamuflowany, podczepione pod zupełnie niezwiązane Prawo Spółdzielcze, proponowane zmiany (Art. 44 str. 16) przekształcają opcję z nuklearnej w termonuklearną.

Po pierwsze, zwiększenie dostępności. Obecnie procedurę inicjuje uchwała wspólnoty. Uchwały mają to do siebie, że trudno zebrać podpisy większości właścicieli. Po zmianach, każdy współwłaściciel, któremu nie podoba się płacenie za dłużnika, będzie mógł wszcząć procedurę.

Po drugie, wystarczy półroczne zaleganie z opłatami. Z jednej strony próg jest dobry, bo obecnie nie ma żadnego zdefiniowanego i sądy często oddalają powództwa. Z drugiej strony, opłaty za 6 miesięcy to 1 - 1,5% wartości mieszkania. Zdecydowanie za mało na licytację.

I po trzecie, już nie tylko długi mają być powodem licytacji. Również zakłócanie spokoju i bycie uciążliwym dla innych. Jakby artykuł 51. Kodeksu Wykroczeń nie wystarczał. Takie uwarunkowanie licytacji jest grubym przegięciem ze strony ustawodawcy.

Z kolei następny podpunkt trochę wyjaśnia intencję zmian. Wymuszone wyłączenie lokali wskazuje, że chodziło głównie o deweloperów, którzy np. uchylają się od opłat za niesprzedane mieszkania. Jednak to tylko zgadywanka, a same przepisy dotyczą wszystkich współwłaścicieli. Interes i zawartość portfela kilkudziesięciu właścicieli są dla mnie ważniejsze, niż portfel pojedynczego dłużnika, niemniej mam wrażenie, że szykuje się kolejny legislacyjny bubel.

Archived comments:

Sigvatr 2013-07-31 17:18:26

Ale kto kupi mieszkanie z mieszkańcem do wyeksmitowania, co jest dość karkołomnym zajęciem:)

sprae 2013-07-31 21:01:27

Sigvatr: Są specjalni sublokatorzy, którzy utrudniają życie takim ludziom.

Sigvatr 2013-08-01 16:59:56

To to jest zawód? A ja głupi na studia chciałem iść!

sprae 2013-08-02 05:05:41

Studenci to amatorzy. Zawodowy sublokator musi być bardziej pojechany ;-)

Recently, Michael Stapelberg prepared a detailed listing of systemd's component sizes. It clearly shows how much space is really required, and how much space can be saved by giving up various optional components of systemd. It's a nice document. On the other hand, how much we can save by dropping legacy shell utilities?

Let's take some hypothetical system not designed to be accessed interactively by sysadmin. You may call it embedded, you may call it minimal cloud image or just specialised spin/just-enough-OS. We are going to remove all the tools which duplicate functionality already provided by systemd.

Above binaries are needed because they’re doing something plain shell scripts can’t do – syscalls. Growing number of Linux API can be manipulated by means of echo, mkdir and ln, but there always will be need for some syscalls.

By removing legacy utilites, we save total of (magical) 640 kilobytes. Not much. Probably not worth the hassle. What else can we remove? /usr/sbin/hostname (20 304 bytes)? start-stop-daemon? vcsonsole setup, quotacheck, sysctl, cryptsetup, syslog, acpid?

Sizes were collected on Fedora 20 amd64 system.

Archived comments:

Stanisław 'dozzie' Klekot 2013-07-17 23:32:33

Erm.
/usr/bin/cd -- What is this? I've never seen such binary (probably because it's impossible to expose chdir() as an external command).
/usr/bin/umask -- The same. What is it?
/usr/bin/su, which is rarely located in /usr/bin, is pretty much required anyway for any system that is not horribly crippled (mainly for interactive use; I do not consider it a tool to use in scripts).

syslog virtually cannot be removed from system. systemd's journald is not (and doesn't seem to be going to be) a sensible solution for general-purpose logging and it focuses on collecting logs on a single host. Unattended or embedded system should be able to log to some remote destination.

And all the rest of your breakdown, it's actually useless. You try to measure size of executables for purposely-built system, but you take references from a desktop OS. You haven't even scratched surface of special purpose systems (BusyBox anyone?).

zdz 2013-07-18 08:38:04

% cat /usr/bin/umask
#!/bin/sh
builtin umask "$@"

And other builtins in similar manner.
For busybox, I'm not sure if it provides ”enough Linux” to run systemd.

Stanisław 'dozzie' Klekot 2013-07-18 10:10:25

Okay, and how do you expect that to affect *parent* process you issued the command in? Because bash and zsh don't take the shortcut of trying to execute the script in the same process.

shasta 2013-07-18 20:48:45

dozzie, you say that syslog cannot be removed? Well, apparently Lennart sees things differently ;-)
http://thread.gmane.org/gmane.linux.redhat.fedora.devel.announce/1117/

Stanisław 'dozzie' Klekot 2013-07-18 21:05:19

Of course he sees things that way. He is the creator of journald. But hey! Suddenly there is still a need for syslog!

Journald can't operate sensibly in installations intended for no interactive sessions. There just has to be remote logging possibility, and that journald doesn't provide.

Journald is pretty much only good for desktop cases. It will do for Fedora, as I don't know of anybody using it on servers anyway, but it's way too crippled logging solution to replace syslog altogether.

You may read a bit of Rainer Gerhards' articles about journald, shasta. He's the author of rsyslog, so he is biased the other way (but very little, I think) -- this should straighten your view on logging.

shasta 2013-07-18 23:04:43

Why do you think my view on logging needs straightening? :-) I didn't say I agree with Lennart.

I am a big fan of syslog-ng, plus - as a long time Slackware user I don't see journald/systemd crawling into my bed anytime soon. Honestly, I'm just a spectator for this whole systemd drama, watching it from a safe distance. ;-)

And as for work, well, I will always have to deal with some sort of crap anyway, so whether this is Solaris 8 or systemd - doesn't make much of a difference to me ;-)