Profile

Cover photo
Oleksandr Natalenko
Works at Mac-Service Ltd.
Attended National Technical University of Ukraine "Kyiv Polytechnic Institute"
Lives in Kyiv
252 followers|29,450 views
AboutPostsPhotosYouTube

Stream

Oleksandr Natalenko

Shared publicly  - 
 
 
From +Jim Zemlin  #apachecon  keynote this morning on the role of foundations in the software space. Here's his take his own role as executive director at The Linux Foundation. 
1
Add a comment...
 
 
This is a Real security problem and, thanks to a company that jumped ahead of the gun with the news, it's effectively a zero-day vulnerability leaving everyone else scrambling to get the patches out. 
1
Add a comment...

Oleksandr Natalenko

Shared publicly  - 
 
 
Q: How can you tell when a kernel maintainer is European?

A: He describes some of the changes as written by "Alexandre Belloni, Jean-Jacques Hiblot and other French people".

.. because clearly it's too hard to keep track of all those French people that presumable nobody cares about anyway. 

Heh. 
1
Add a comment...
 
 
To clarify a few things regarding that "debug" mess:

I will change systemd to not log to kmsg if journald is around when "debug" is specified. We will continue to log to kmsg during the early bootphase however als long as journald is not running yet. At that point there is simply no other option for that, because persistent storage is not available yet at that point and we need som way for people to get their logs out of the system, and early kmsg is the only way really, since it is hooked up with netconsole, serial tty, crashkernels, ... and all that other stuff.

I also believe that it is the right thing for the kernel to ratelimit whatever userspace sends it. For the same reason as we have to ratelimit all log streams in journald too, regardless where they come from. If you get a stream of logs from a 'differently priviliged' component then you need to rate limit it, that should be common sense. Of course I wish the ratelimiting applied is always configurable for the user, so that he can control how much and how soon things get dropped.

For me it is out of question though that systemd and other core os components should continue to parse the 'debug' kernel cmdline option, and increase their debug levels then. Generic options like that are supposed to be useful for real people, and there's a long history of options like that which influence both kernel and userspace (quiet, root=, ...). We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail. We are writing an OS here for the general purpose, not just a toy for a clique of kernel developers. Moreover, there are individual kernel cmdline options for both the kernel itself and systemd to control just their log levels, and nothing else. so if you want finegrained control, you already have it, 'debug' is just the simple option that groups them all under a single oneshot option. It's the option an admin can specify which tells him why the system doesnt boot, regardless whether the kernel or systemd is at fault or any other part of the core os involved in boot. Thats simply userfriendly.

I do not appreciate all that talk from certain parts of the community that the systemd folks need to 'get tought a lesson'. That turns this into some kind of power game, which I am totally not interested in. Comparing us to Putin, or trying to bind merging of completely unrelated code to us doing whatever some kernel devs want (which is blackmail at worst, and childish at best, and childish we can be on our own enough, thanks) will just make us ignore you, and that's it. I prefer to deal with technical questions, and intimidation is not a technical question.

what the various news outlets wrote about all this is quite ridiculous. It's sad how badly these sites report, quite a shame.

And that is all.
1
Add a comment...
Have him in circles
252 people
Сергей Лемеш's profile photo
Олег Точенюк's profile photo

Oleksandr Natalenko

Shared publicly  - 
 
This release introduces nothing new but fresh ports of components to 3.14 branch. Many thanks to +Arianna Avanzini  for BFQ resync against 3.14 tree (looking forward to v7r3!), Nai Xia, Felixonmars and Marco Benatto for UKSM port, Alfred Chen for BFS port and +Nigel Cunningham  for keeping TuxOnIce fresh.

https://pf.natalenko.name/forum/index.php?topic=257
1
Add a comment...

Oleksandr Natalenko

Shared publicly  - 
 
 
. If anything can go wrong, it will.
. If you change queues, the one you have left will start to move faster than the one you are in now.
. Your queue always goes the slowest.
. Whatever queue you join, no matter how short it looks, it will always take the longest for you to get served.
(Murphy’s Laws on reliability and queueing)

[http://irh.inf.unideb.hu/~jsztrik/education/16/SOR_Main_Angol.pdf]
1
Add a comment...
People
Have him in circles
252 people
Сергей Лемеш's profile photo
Олег Точенюк's profile photo
Work
Occupation
Telecommunication researcher
Skills
Linux
Employment
  • Mac-Service Ltd.
    System administrator, 2013 - present
  • Janus WWI
    Technical translator and editor, 2010 - 2012
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Kyiv
Previously
Novi Sanzhary - Komsomol's'k, Poltava region
Links
Contributor to
Story
Tagline
Proud penguing among bitten apples.
Introduction
Linuxoid, system administrator, network architector, programmer
Bragging rights
pf-kernel author; ruTorrent Ukrainian localizator
Education
  • National Technical University of Ukraine "Kyiv Polytechnic Institute"
    Telecommunication systems and networks, 2007 - 2013
  • Novi Sanzhary Educational Complex
    1996 - 2007
Basic Information
Gender
Male
Other names
post-factum