Korpo, w którym pracuje dostało ostatnio kary. Szef szefów napisał do wszystkich, że jesteśmy w plecy 76 milionów dolarów. Ale mamy się nie martwić, bo jest w budżecie rezerwa i pracownicy nie będą musieli dopłacać. A w ogóle to wina Chińczyków.

Zaczęło się od tego, że zaczęliśmy dla nich robić silnik do helikoptera. Do 12 miejscowego transportowca. Takiego latającego busika. W końcu znamy się i na silnikach (Pratt&Whitney to my) jak i helikopterach (Sikorsky Aircraft to też my). Wszystko szło świetnie, helikopter latał, więc nasi inżynierzy polecieli do Chin zobaczyć jak się spisuje.

I się zdziwili. W helikopterze brakowało 10 miejsc. Za to były jakieś karabiny, działka, miejsce dla strzelca itp. Na zdziwione “No!” i “Non!” (nasi byli z Kanady) Chińczycy odpowiedzieli, że gdzieś tam wspominali, że równolegle z wersją cywilną opracują też latadło wojskowe.

I faktycznie mają również helikopter cywilny. Ale to zupełnie inna konstrukcja, tonę cięższa i w związku z tym używająca silników produkcji francuskiej, bo nasze się nie nadały. My na pocieszenie mamy kary za handel bronią z Chinami. I strasznie słabe cover story w które nikt nie wierzy.

Sprawę w szczegółach opisał Sean Gallagher na łamach arstechnica.

Archived comments:

torero 2012-07-07 21:51:21

Słowa kluczowe "Chiny" oraz "broń" wygenerowały u mnie potrzebę zamieszczenia nie aż tak znów offtopicznego linku:
http://kaleson987.wrzuta.pl/audio/9KWFx0fzXeK/piotr_bukartyk_-_anonimowa_zolta_raczka

More and more distributions ship unit definition files as a part of systemd integration. Sadly, upstreaming effort is very low profile and downstream units begin to diverge. I’ve spent some time during last month to push unit definitions upstream into the software I use.

Starting with ladvd. Actually, Sten merged service unit definition about a year and a half ago. Recent changes in systemd allowed unit to be simplified.

Next was hdapsd. Evgeni preliminary accepted patches, so it seems systemd unit will make into the first hdapsd commit in three years. Probably together with other patches waiting, like HP and Apple notebooks support. My patch contains udev rule, as this is an example of hardware-activated service.

I also patched rrdcached, implementing socket-activation and providing two units definitions. Tobias merged my patches in trunk. This gives us timely, on-demand start up and no lost connections even during rrdcached restart.

uptimed will ship unit files in 0.3.18, also. Radek is the new upstream and he happily took patches.

I also have got a patch for aiccu, but I did not send it. There was no upstream activity in the last 5 years and I'm not entirely happy with my patch, as it disturbs platform-agnosticy. I've implemented Type=notify behaviour, marking unit active only if tunnel was established. That makes After=aiccu.service work in expected ways.

Writing unit definition is simple. Hooking up autotools stuff is more complicated, but man 7 daemon contains very helpful snippets. You may need to add something like AC_OUTPUT([etc/mydaemon.service]) to mangle mydaemon.service.in into mydaemon.service by replacing ExecStart=@prefix@/sbin/mydaemon with whatever prefix was passed to ./configure.

If you do not want to use helper functions provided by systemd, you can reimplement logic directly in the application. For example, look at this simple patch implementing socket activation in iodine.

It is often useful for a daemon to open a default config file. Location of this file should be provided at build time. Debian tend to use /etc/mydaemon/mydaemon.conf location, while Fedora is more about /etc/mydaemon.conf. Removing the path from the unit file makes it simpler and more reusable between distributions.

You want to test the unit file in the field, typically in Rawhide or similar distribution. After a release cycle or two, when you have all bugs ironed out, you should submit unit file upstream.

Looks like Collabora's efforts to bring D-Bus into the kernel are getting close to release. It's not a revolution, but it is really nice to have.

From my perspective, the D-Bus daemon has three main tasks:

• deciding where messages should be delivered (routing)
• actually delivering messages
• starting delivery sources on-demand

Third point is already intercepted by systemd and upstart (BusName= and start on dbus-activation), so we are left with message delivery and routing.

D-Bus messages have source and destination, sometimes multiple destinations. Just like TCP/IP packets, which sometimes have multicast destinations. For TCP/IP, we already have world-class delivery stack in Linux. And we have clear separation between mechanism — kernel TCP/IP stack using routing table to forward packet — and policy — routing deamons like quagga or bird. Routing daemons manipulate routing table in kernel, but are not needed to actually move the packets.

That's how I see D-Bus—in—kernel. The kernel moves the message. D-Bus daemon should only modify kernel routing table putting “deny” and “allow” where appropriate. D-Bus daemon will no longer deliver messages, leaving message juggling to kernel. This separation will fix long-standing problems with D-Bus deamon early start and restarts. Message passing will be available all the time, D-Bus routing daemon won't need to run uninterruptably. Or at all.

Just like basic networking works right now without routing daemons.

Archived comments:

mh 2012-06-20 14:41:31

Yay! Do you know if/how will be implemented sniffing?
Currently there is dbus-dump[1] which uses strace (sic!) attached to dbus-monitor process.
If message passing will be in kernel, we can't use strace ;/

[1] https://github.com/mvidner/dbus-dump

z 2012-06-20 14:59:02

I guess pcap interface will be extended, so tcpdump will work with it. Just like it allows sniffing USB & Bluetooth traffic now (see "tcpdump -D").

Khorne 2012-06-20 16:39:28

Nice! I love the idea, esp. for embedded Linux systems. Very useful.

Rich 2012-06-21 09:47:25

Oh dear, we need less dbus not more.

Khorne 2012-06-21 09:58:39

@Rich: why do you think that?

I've seen a lot of devs reinventing the RPC wheel with shm, sockets, pipes and whatnot. Dbus is a good solution to that problem.

Prawie półtorej dekady braku większej styczności z platformą MS Windows spowodowało, że zupełnie nie kojarzy mi się ona z komputerami określanymi jako PC. Opowieści o wyglądzie Windows 7 czy 8 mają dla mnie posmak wizyty w zoo. Owszem, gdzieśtam żyją antylopy i żyrafy, ale codziennie życie wygląda zupełnie inaczej.

Analogicznie z obsługą hardware. A kiedyś przecież prezentacja obsługi USB przez Windows była równoznaczna z prezentacją możliwości samego USB! Śledziło się newsy o zmianach czynionych przez Microsoft i oglądało obrazki z wersji testowych z odczuciem zerkania w przyszłość.

Zarysowanie się w społecznej świadomości Mac OS X i rozszerzenie rynków, na którym Microsoft nie dominuje (tablety, komórki, urządzenie wbudowane)... zanika zależność sprzętu od konkretnego systemu operacyjnego. Nowe technologie nie pojawiają się dopiero wtedy, gdy Windows ma do nich sterowniki.

Obecnie dziwnie mi się odbiera szum typu w 2012 Thunderbolt będzie szeroko obsługiwany. No jak, przecież obsługa TB była już rok temu, teraz pora zająć się ciekawszymi, nowszymi rzeczami (np. 802.11ac). Thunderbolt w Linuksie po prostu działa, nie ma nad czym się zastanawiać. Podobnie jak z USB3.0. Nota bene, cztery lata po wprowadzeniu standardu, obecny Windows nadal nie obsługuje go sam z siebie.

Archived comments:

sprae 2012-06-18 18:33:20

Jeśli chodzi o Metro, to tu jest ładnie i jasno wytłumaczone z czego ono czerpie. http://channel9.msdn.com/Series/Projektowanie-aplikacji-w-stylu-Metro/Czym-jest-Metro--Projektowanie-aplikacji-w-stylu-Metro-cz-3
Równie dobrze mógłbyś pokazać paski narzędziowe jakiś starszych aplikacji i porównać z tym co zapodałeś.

Co do hardware to Windows nie było nigdy nadzwyczaj szybkie w jego implementacji. Chodzi o taka dogłębną, a nie tylko żeby działało. Bo tyle to zapewni każdy producent.
To samo było z x86-64. Linux obsługiwał praktycznie od początku, ale dopiero teraz zaczyna mieć to sens. Zarówno wydajnościowy jak i optymalny.
Każdy system ma jakieś syfy. Niektóre z nich wychodzą np. w Androidzie. Co potwierdził nawet Intel. Linux ma tą zaletę, że jest gruntownie przetestowany taki jaki jest, mając przy tym duże możliwości i dlatego warto go wkładać w różne specjalizowane urządzenia bardziej niż jakiś RTOS czy BSD.

darkjames 2012-06-18 22:18:55

x86-64? x86-x32 jest teraz na topie :)

z 2012-06-19 09:20:08

darkjames: x86-32 jest na topie chyba pośród gentoowców. Intelowa zabawka, dla słabo wyposażonych andoridowych telefonów na x86.

Taka mała nowelizacja prawa mi się zamarzyła:

Samochody zarejestrowane na firmę powinny być oznaczone logotypem i nazwą firmy która je posiada lub leasinguje, umieszczonym w widocznym miejscu, o wymiarach co najmniej 25x15cm.

Archived comments:

LCF 2012-06-15 21:56:42

http://a4.sphotos.ak.fbcdn.net/hphotos-ak-snc7/475318_307223906026476_1413477501_o.jpg

Liczy się ?

pecet 2012-06-15 22:07:08

dlaczego, chcesz karać kogoś za to że lepiej od ciebie zarabia lub prowadzi działalność gospodarczą?

heh 2012-06-16 01:14:24

@pecet: bo jest polakiem.

webpage scanner 2012-06-16 09:17:07

a co z samochodami firmowymi które mają zostać "cywilne" - np wewnętrzna kontrola?

zdz 2012-06-16 10:04:52

LCF: z uwagi na to, że koty są super, można zaliczyć.

Pecet: dlaczego uważasz, że to miałoby znaomiona "kary"?

ws: nie widzę uzasadnienia.

Remigiusz 'lRem' Modrzejewski 2012-06-16 12:58:21

A ja się spytam: po co?

zdz 2012-06-16 14:45:46

Lrem: w przypadku dylematu "jebnąć czy nie jebnąć" spełniałyby rolę analogiczną do emblematów "baby on board".

Remigiusz 'lRem' Modrzejewski 2012-06-16 14:48:30

W sumie racja. Jestem za.