przemoc

True, but even though you can set:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
    "RealTimeIsUniversal"=dword:00000001

~8 years ago I was using LD_PRELOAD to be able to (s)fdisk fixed-size VDI image (VirtualBox Disk Image) outside of virtual machine.

https://gist.github.com/przemoc/571086

Don't know if it still builds and works flawlessly.

NetEm seems to be rarely known and used traffic control feature available on Linux.

The linked script allows you to delay sending DNS requests (IP packets with destination port set to 53) on given interface. Normally it is useless, but it may be useful for debugging some hard network-related cases in your software.

The script may also work as a base for other network-related experiments using netem. You can read more about it here: http://man7.org/linux/man-pages/man8/tc-netem.8.html

Just out of curiosity (it's not my field), what are those 3 renderers that matter right now?

Somehow I read your comment as V-Ray is not among them as being last-gen. I remember that years ago there was a lot of buzz regarding Arnold (and it was justified to some extent AFAIR, at least judging by opinions of pleased 3D crowd), but maybe it's last-gen too now? Many years ago there was Brazil, but quick googling shows it's only for Rhino now? I haven't heard about Redshift till now, though.

Somehow title lost @ at the end. Is it some kind of forbidden character?

Can be useful. Thanks for sharing!

I usually used sxc.hu so far, which became FreeImages.com some time ago.

Similar thoughts. :)

He's author of great stuff out there, but I think his works should be treated more as showing the way of doing this or that than making you stick to his particular implementations (I'm not implying they're bad, though). For instance I prefer runit over daemontools, but quite likely without daemontools there wouldn't be runit. (Actually I want to try s6 [1] soon, as it seems another step in evolution of process supervision tooling.)

But his "build system" is actually unnecessarily non-standard and clunky. I am against autohell, but carefully crafted handmade Makefiles are really nice.

  [1]: http://skarnet.org/software/s6/

It's MLT, not MELT.

And it's a base for other video editor, which is getting stronger each year, seems more stable than the others and already looks IMHO the best among FOSS video editors:

http://www.shotcut.org/

I think that metastore will become much more valuable tool, when some planned stuff will be implemented.

https://github.com/przemoc/metastore/issues/6

https://github.com/przemoc/metastore/issues/7

Drafts described there are not finalized and my view on some matters changed a bit. I'll try to update descriptions one day. metastore needs also some modularization to provide better OS-dependent stuff like xattrs.

All in all metastore will need more or less substantial reworking, to the point where rewriting it and providing converter from binary format may be a simpler solution and leading to cleaner (and thus more maintainable) code.

Let me quote README file first:

    It was originally written as a supplement to git, which does not store
    all metadata, making it unsuitable for e.g. storing /etc in a
    repository.
    
    metastore can also be helpful if you want to create a tarball of a file
    tree and make sure that "everything" (e.g. xattrs, mtime, owner, group)
    is stored along with the files.

metastore was used in etckeeper in the past.

https://joeyh.name/blog/entry/announcing_etckeeper/

In less than half a year it was replaced with find scripts.

http://git.joeyh.name/?p=etckeeper.git;a=commitdiff;h=a9ce99...

And I cannot blame etckeeper. Using binary format for storing metadata, i.e. owner, group, perms, xattrs, mtime, makes it too opaque for many use cases, especially in VCS.

metastore v1.1.0, as you can already read, was meant to give metastore (from 2008) a proper release, with fixed bugs and small improvements only. There are plans to make metastore more useful in the future, though.

I guess that some mod intervened here (by bringing this closer to the front page), because even a few hours after posting there were only a few points and it was rather deep in HN. Thank you!

Post title has been also changed, and it's fine. I no longer remember mine, but it was maybe too clunky. But.

metastore should be written using all lowercase letters.

Code::Blocks was definitely better than horrendously buggy Dev-C++, but since Qt Creator I never looked back (ok, I do use vim very often, but it's a different thing). To be fair I haven't checked Code::Blocks for years (8 years at least), so maybe nowadays it gives more than notepad+syntax-highlight+tabs feeling.

BTW Everyone, please write "Qt Creator" with space between "Qt" and "Creator". I don't know how spaceless variant got so widespread.

There was another mail sent to ML regarding v1.1.0:

https://www.freelists.org/post/metastore-announce/metastore-...

Changing topcolor in settings from ff6600 to something else (like ff6601) brings back the right^TM color.

Far Manager is the first application I run in Windows. Always.

Lately I've noticed that my Far and plugins set diverged slightly on different computers, so I decided today to create kind of bootstrap script, so I could easily recreate them.

It's maybe not the cleanest script and lacks a bit of scaffolding to even further ease adding plugins, but it's already usable.

Currently following plugins are added:

  - Integrity Checker
  - Regular Expression Search
  - Renewal
  - Renewal-supported plugins, i.e. FarPlugs:
    - Audio Player
    - CoderCalc
    - Disk Menu Editor
    - File Unlock
    - HashCalc
    - Hexitor
    - Hunspell
    - Image Viewer
    - JClassInfo
    - Media Info
    - Name Editor
    - PE Analyzer
    - PortaDev
    - Sniffer
    - Sqlite DB
    - Sudo
    - TextConv
    - Torrent Info

http://forum.farmanager.com/viewtopic.php?f=28&t=9835

While it's true that Michael generates lots of merge commits, if you click the link in LWN article to Andreas Cadhalpun's mail [1], then you can read that following commands were used to generate statisticts:

  Libav:
  $ git shortlog -ns --no-merges v11..HEAD | head -n15
  FFmpeg:
  $ git shortlog -ns --no-merges n2.4..HEAD | head -n15

  [1] https://lwn.net/Articles/650830/

About what "Lossy FLAC" you're talking about? Do you mean perhaps [1]?

If FLAC would ever gain a lossy mode, it would be a disaster, because it would be instantly (ab)used and it would be misleading to a lot of users. "FLAC is not Lossy" [2] and it will hopefully remain that way forever.

(Of course it doesn't prevent people from encoding audio into FLAC from lossy formats, but it's a completely different matter.)

  [1] http://www.hydrogenaud.io/forums/index.php?showtopic=55522
  [2] https://xiph.org/flac/features.html

FWIW, Google Maps are generally noticeably slower and laggier in Firefox when compared to Chrome.

If you're *nix user, you can quite easily perform this kind of stuff using date, or at least using date from coreutils.

    $ date -d 'today + 6 weeks'
    Mon Aug 24 13:15:54 CEST 2015
    
    $ TZ=America/New_York date -d 'now + 2 hours'
    Mon Jul 13 09:16:17 EDT 2015

It always felt natural to put this dot at the end of (what antirez nicely called) commit synopsis, so AFAIR I always (or at least since I started using git and when was not forced by particular project's rules to do some other way) put it there and found advices to avoid it quite strange. The only exception (beside forgetting about full stop yet pushing to public repo, it does happen sometimes) I have is when the commit is sole version-bumping/releasing one, because then I usually go with following style

    PROJECT_NAME [v]VERSION

As some commenters here already wrote, it's not a grave matter, but it's good to have consistent style. It goes without saying, that having relatively short commit summary in one sentence separated with blank line from further details (if they are necessary) is far more important matter than the period or lack thereof, as it immensely eases groking commit log.

Thank you for such a prompt answer.

EDIT:

Quick googling revealed that Rust doesn't work with musl libc yet. It will be really nice when it will be fixed.

Now that Rust reached v1.0, I may finally look into it without the fear of wasting time to learn stuff that will change within next months. (It's quite sad, though, that recently released Debian Jessie won't have it in its main repositories.)

Allow me to ask some questions, because I cannot easily find the answers and they're IMHO crucial for wider Rust adoption:

1. What CPU architectures/platforms Rust currently supports?

2. What's the state of cross-compilation support?

Most of devs have workstation on i386/amd64, but some of us may work with ARM, PowerPC and other architectures. Rust's memory safety seems appealing for embedded solutions, but can it be used there already?

BTW The install page is not well-thought-out.

http://www.rust-lang.org/install.html

Unless I hover on the 32-bit/64-bit links and read addresses they point to, there's no way to tell whether it's for x86 or ARM for instance. And installation via piping script that is being downloaded to shell is something that shouldn't be present at all.

Thanks for mentioning Super User's BSD Cross Reference (bxr.su)! Apparently there are many more OpenGrok installations nowadays than it used to be 5 years ago.

https://github.com/OpenGrok/OpenGrok/wiki/OpenGrok-installat...

EDIT: Not all of them are working, though.

Jakub Jelinek's announcement on ML:

https://gcc.gnu.org/ml/gcc/2015-04/msg00287.html

And the same one for gmane lovers (like me):

http://thread.gmane.org/gmane.comp.gcc.devel/139625

I am not a Mac user, so cannot tell whether it's really "especially on the Mac", but I totally agree that most FLOSS with GUI has bad look and often bad UX too. It's easier to find well-thought-out polished CLI/TUI tools than GUI ones (at least on Linux). And no, making terminal apps is not always easier than windowed ones.

Why open source GUIs are bad or inferior to TUIs? I think it's a good question and I dare to say it's definitely not the lack of skills within open source community. Maybe it's mindset-related?

I noticed that the most activity in open source is backend-related, if you know what I mean. People solving "real problems" in kernels, servers, daemons, agents and what not, may see graphical frontends as not important, often bringing additional complexity possibly not worth the trouble.

I could call myself a backend guy too and I think I like working on backends more than frontends, especially GUI frontends (well, I haven't touched GUI frontend matters for some time already, at least any sane one). I believe (maybe I'm wrong?) I am able to do some decent GUI, but somehow I never do them nor really need to do them.

I very much appreciate lot of open source work out there. I find it truly amazing how people find time, energy and motivation to work on something pro publico bono in their spare time. I like the idea and want to be more open-sourcy myself (meant as contributing to open source), but I always struggle to squeeze time and/or energy after work to really do it. (When I am even successful in managing to do OS activities, I don't have much time, so I fiddle then more with my old pet projects covered in dust than anything else, because becoming productive in other software needs much more time. Well, I do some bug reports or send fixes sometimes, but it's not more than a few up to several in a year.)

At the same time I always think and tell others, that open source shouldn't use some special standards, just because people working on it do it voluntarily and are not paid for. We should always aim for the best possible, not mostly working/ok-ish things. Telling devs that UI/UX of their project sucks for instance, doesn't mean we diss these developers. As a developer you should never take critique of the projects you're involved in personally. And constructive critique is always great way to improve our own views, because we're all biased, especially the creators of their own child projects. So while telling that UI sucks may not be constructive, following it with list of problems it has, becomes constructive. There are also these rare cases, when we feel that something is clunky and out of place, but we cannot pinpoint what exactly is wrong here...

OTOH users do not always understand that GUI is usually tip of the iceberg, and even if the tip is massive in some apps, it's still connected to stuff under the hood, and some refactorization may be needed to be able to present decent and responsive GUI that would replace the one previously available. We may try to criticize that devs didn't do their job properly if refactoring is needed for "tiny" GUI improvements and we may be right to some extent, but it's impossible to thought-out everything beforehand.

Last note regarding special standard. In fact many open source backend stuff out there is better than proprietary ones, so this special standard I mentioned before can be also meant positively. But it's also true that many of such successful open source projects do have paid developers after all.

EDIT: typos

XP was RTMed on August 24, 2001 and GA was October 25, 2001.

But I can understand why you wrote what you wrote. Early XP experience for many remains repressed memory, because it was quite buggy (be it OS itself or drivers delivered with it, BSODs were a norm), far from stable 2000 SP4, which I kept using for a long time. XP around SP2 (August 25, 2004) got usable.

Obligatory archived copies of above mentioned pages:

[1] https://archive.today/Pw2gr

[2] https://archive.today/2lHs7

[3] https://archive.today/gc1Gu

[4] https://archive.today/knFJg

[5] https://archive.today/8BFxh

[6] https://archive.today/9EkxY

The topic was modern C and in modern C environment NULL is defined as

    (void *)0

C++ is another story with its

    void* hate

    (type*)0

    (type*)NULL

    static_cast<type*>(0)

In many cases you can be done with 0 alone in C++, that's true, and in such cases NULL at least poses some intention, but if you're not careful enough, you may end up putting NULL alone (without pointer-to-type cast) in some variadic function and things start to blow up all of a sudden (that is if your NULL integer width isn't the same as pointer width). That's why having a habit of writing

    (type*)0

Regarding musl check also:

http://git.musl-libc.org/cgit/musl/commit/include/stddef.h?i...

In short, musl's stddef.h has following lines:

    #ifdef __cplusplus
    #define NULL 0L
    #else
    #define NULL ((void*)0)
    #endif

In the same vein for Windows C++ x64 environment you need NULL to be 0LL, as it is LLP64 platform.

I didn't know about use of static keyword in array parameter declaration, but I dare to say that a lot of senior C programmers are unaware of this C99 feature.

It's nice to be able to specify function's expectations on that level, yet it looks that only clang (tested with 3.5.0) takes use of it, while gcc (tested with 4.9.1) seems oblivious to it. Be it NULL or shorter string literal than expected, gcc with -Wall -Wextra -pedantic -std=c99 spits nothing. Both mistakes are detected by clang.

Sadly even clang doesn't warn us when fun(int len, char str[static len+1]) is called like fun(5, "test").

But I'm not sure that I agree with the rule 2.11.7.1 Don't use NULL. In any sane C environment NULL is defined as follows (unless __cplusplus is already defined, because then it's defined as 0 or 0L)

    #define NULL ((void*)0)

Distinguishing kind of 0 we're dealing with (even if it's not strongly guarded by compiler) is often important for readability and eases maintenance of the code (0 vs '\0' vs NULL). While comparing pointer with NULL (writing p == NULL or p != NULL instead of simply !p or p) may seem superfluous (yet I have nothing against programmers doing so), calling function with pointer parameters providing 0 argument instead of NULL seems less clear to me.

if you really want to emphasize that the value is a pointer use the magic token sequence (void *)0 directly.

I don't buy it.