IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Instead of copying fields into new memory allocations, simply keep pointers
into the receive buffer. Data in this buffer is only copied when there is not
enough space for new data and a large chunk of the buffer contains old data.
Define DATA_SIZE_MAX to mean the maximum size of a single
field, and ENTRY_SIZE_MAX to mean the size of the whole
entry, with some rough calculation of overhead over the payload.
Check if entries are not too big when processing native journal
messages.
Previously existing scheme where the file name would be based on
the source was just too ugly and unpredicatable. Now there are
only two options:
1. just one file (until rotation),
2. one file per source host, using the hostname as filename part.
For the cases where the source is specified by the user, only
option one is allowed, and the full of the file must be specified.
Directory src/journal has become one of the largest directories,
and since systemd-journal-gatewayd, systemd-journal-remote, and
forthcoming systemd-journal-upload are all closely related, create
a separate directory for them.
If a file was opened for writing, and then closed immediately without
actually writing any entries, on subsequent opening, it would be
considered "corrupted". This should be totally fine, and even in
read mode, an empty file can become non-empty later on.
Let's turn resolved into a something truly useful: a fully asynchronous
DNS stub resolver that subscribes to network changes.
(More to come: caching, LLMNR, mDNS/DNS-SD, DNSSEC, IDN, NSS module)
It appears there is no good way to decide whether or not broadcasts should be enabled,
there is hardware that must have broadcast, and there are networks that only allow
unicast. So we give up and make this configurable.
By default, unicast is used, but if the kernel were to inform us abotu certain
interfaces requiring broadcast, we could change this to opt-in by default in
those cases.
On Tue, Jul 15, 2014 at 1:52 PM, Alick Zhao <alick9188@gmail.com> wrote:
>>>
>>> So maybe ID_SOFTWARE_RADIO ?
>>
>> Hmm, SDR is more a term for a generic technology than for a device
>> class. To me it does not really sound like an administrator would know
>> what this is.
>>
>> What exactly is the device or subsystem you want to make accessible to
>> locally logged-in users only?
>
> Initially it is bladeRF, but many more are of interest: USRP, rtl-sdr,
> HackRF, ... [1]
>
> I agree an administrator might not know what SDR is, since it is
> currently still not widely known, and makes sense only for amateurs
> and researchers. But as a SDR fan, I see many new SDR peripherals
> are created recently, and expect to see more. So a generic ID seems
> reasonable to me.
>
> [1] http://en.wikipedia.org/wiki/List_of_software-defined_radios
