Wpisy

Opublikowane w

6 stycznia wolny – zysk czy strata dla pracowników?

Od pierwszego stycznia zmieniają się prawo pracy, a konkretnie zasady udzielania dni wolnych. Do tej pory, jeśli dzień wolny od pracy przypadał w sobotę, to pracownikowi przysługiwał w zamian za niego dzień wolny. Od 1 stycznia 2011 nie ma tego, za to do świąt dołącza 6 stycznia jako Objawienie Pańskie.
Zasadnicze pytanie: czy pracownicy na tym zyskują, czy tracą? Odpowiedź na to pytanie wbrew pozorom nie jest oczywista.
  • 1 stycznia
  • 1 maja
  • 3 maja
  • 15 sierpnia
  • 1 listopada
  • 11 listopada
  • 25 grudnia
  • 26 grudnia

(pomijam 4 święta ruchome, które w Polsce nigdy nie wypadają w sobotę), a do tego dochodzi od tego roku 6 stycznia.

Nie wdając się w matematykę (jakoś nie mam głowy do matematyki kalendarzowej, a nic sensownego mi nie wyszło przez chwilę namysłu), korzystam z metody najdoskonalszej, czyli pełnego przeglądu (AKA brute force) wg algorytmu: jeśli któreś z dotychczasowych świąt wypadnie w sobotę, to pracownicy tracą dzień, jeśli 6 stycznia nie wypadnie w sobotę ani w niedzielę, to pracownicy zyskują dzień.  I sumowanie strat i zysków…

Całość to nieładny bash (funkcja date) napędzana perlem, pisany na szybko.

Wynik? Miłe złego początki – przez najbliższe 10 lat stracimy, jako pracownicy, średnio rocznie 0,1 dnia wolnego, a w pierwszych 3 latach nawet będzie niewielki zysk, ale dla 25 lat – o ile przepisy się nie zmienią – stracimy łącznie 8 dni wolnych, czyli 0,32 dnia wolnego rocznie. Szczerze mówiąc, nie jest tak źle jak myślałem…

Ale zmiana jest ewidentnie niekorzystna dla pracowników. Gdyby miała miejsce w 1990 roku, to do tego roku tracilibyśmy średnio ponad pół dnia wolnego rocznie.

I skrypt do obliczeń:

Opublikowane w

Flattr – nowe funkcje.

Powoli zbliża się moment, kiedy chcę zacząć ponownie korzystać z Flattr po tym, jak stwierdziłem, że nie jest gotowy do korzystania z niego. W międzyczasie pojawiły się nowe funkcje:

  • wypłata do Moneybookers – dla tych, którzy nie lubią PayPala. BTW ciekawe na ile jest to związane z przyłączeniem się PayPala do blokady Wikileaks…
  • subskrybcja, czyli automatyczne flattrowanie w kolejnych miesiącach (IMO bardzo fajna opcja dla projektów Open Source),
  • opcja donate w profilu użytkownika, czyli natychmiastowe przekazanie kwoty 2-50 euro (z dostępnych, nie przeznaczonych na dany miesiąc środków),
  • Flattr w wersji offline – no, może niezupełnie offline, bo tak naprawdę chodzi po prostu o QRcode, a połączenie będzie potrzebne, ale już np. na plakacie reklamującym imprezę czy koncert może się znaleźć taki „przycisk” znaleźć…

Tak więc zmniejsza się ilość rzeczy, na które narzekał KosciaK w swoim wpisie nt. Flattr i komentarzach do niego. Konkretnie: są podane organizacje charytatywne, jest opcja donate dla większych kwot (niestety z widełkami i prowizją, ale IMO dobra alternatywa dla PayPala).

Pozostało mi czekać, aż coś wpłynie na mojego PayPala, żeby móc znów uruchomić Flattr…

Opublikowane w

Jak nie szukać pomocy (na IRC).

Co prawda dotyczy IRC, ale przypuszczam, że dla różnego rodzaju forów będzie prawdziwe. Oto krótki przepis, jak nie szukać pomocy w Internecie (zwł. IRCu):

  1. Wejdź na kanał poświęcony jakiejś dystrybucji.
  2. Pochwal się, że własnoręcznie zrobiony kernel nie działa.
  3. Zapytaj dlaczego?
  4. Oświadcz, że UUID są do niczego.
  5. Zapytaj czego nie wkompilowałem?
  6. Oświadcz, że na kernelu dystrybucyjnym działa, ale jest on do niczego, bo coś innego nie działa, a poza tym własny kernel jest boski i überzoptymalizowany.
  7. Nie podawaj żadnych szczegółów nt. niedziałania czegoś innego, w szczególności – mimo próśb – nie podawaj opcji w swoim kernelu, które sprawiają, że działa.
  8. Zaproponuj twierdzącym, że jednak coś innego powinno działać, żeby sami uruchomili coś innego, totalnie im niepotrzebnego.
  9. Oświadcz pomagającym, że nie umieją (chociaż im działa, także na własnym kernelu) i nie jesteś jasnowidzem, żeby wiedzieć, czemu Twój kernel nie działa, bo nie wiesz co się pozmieniało między wersjami dystrybucji.
  10. Wklej linka do bug reporta, gdzie jest fragment z logów, gdzie jak wół stoi, którą opcję trzeba zmienić przy kompilacji.
  11. Oświadcz, że nie czytasz release notes.
  12. Powiedz pomagającym, że są irytujący, zapytaj ich, czy wydaje im się, że są Linux guru i wiedzą, co jest dobre a co złe.
  13. Zaproponuj opisanie sytuacji na blogu.
  14. Nie dziękuj i wyjdź.

W razie wątpliwości: marudź, nie odpowiadaj na pytania lub rób to wymijająco, nazywaj rozwiązania stosowane w dystrybucji głupimi. Przecież wiesz lepiej. Jak najczęściej pytaj dlaczego nie działa?, konkrety podawaj tylko w ostateczności.

MSPANC