Also, systemd and upstart make Linux much less suitable for embedded systems.
Actually, I think it's partly the embedded people who are pushing for systemd. Which worries me, since many of them don't know or care about Unix.
I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you canwrite an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable. So your arguments in favor of binary log files seem quite moot.
Oh, I can see you are quite new to Linux log files, they are basically free form dumps of whatever anything wants to write to syslog in any which way they please. It is impossible to make anything else than a crude GUI; a 'less' just with windows decorations. This is exactly why both Gnome and KDE dropped their previous attempt on making such a GUI.
So, how does making it a binary blob help? The data sources will just produce free form dumps as before, and that's what will end up on the logs. The things that are structured is the time stamp, facility and critical/error/info etc level, and they are easily parseable anyway.
So either the binary blobs don't help at all, or all Unix applications will be forced to adopt some non-Unix structured logging. For my applications, I can say right now I will not do the changes needed to achieve the latter
What I wish was available was a way to view the source of a git with one minor enhancement - the ability to browse with a click to the declaration/definition of functions/variables a la the IDE of your choice. Would be neat to be able to build an index using some tool, check it into the root of your repo, and then have the site use the index to mark up the source code with the appropriate links. I've dug around for something that does this but haven't found anything suitable - anyone know of anything?
Sounds like plain old etags/ctags. You may have to look at the commit from inside your editor though for that to work, e.g. an Emacs M-x shell.
Honestly, if your compile times are that much, and that much of a burden, you need to upgrade, and you also need to modularise your code more. The fact is that most of that compile time isn't actually needed for 90% of compiles unless your code is very crap.
Hint: I said 'two hours to compile from scratch'. You can't avoid compiling all your source if you just did a clean checkout from SVN into an empty source tree; as you would, for example, before building a release or release candidate.
That, to me, sounds like "I don't trust my build system to do an incremental build". A lot of people don't, and end up spending $$$$ on building provably the same thing over and over again, dozens of times a day
BTW, Git does the right thing WRT timestamps and Makefiles: when it changes a real file, it updates the timestamp to the current time, not the time the version was created. Now that I've used it, I don't understand why tools made the wrong choice for thirty years.
OK, that explains why I've been getting away with assuming they wrap since the Clinton administration. I don't know if anybody ever explained it to me in C terms.
It's *your* responsibility as a C programmer to find out what the rules of the game are; you should accept that responsibility. However
I always assumed that behavior was baked in at the CPU level, and just percolated up to C. I never felt inclined to do any "bit twiddling" with int or even fixed-width signed integers because on an intuitive level it "felt wrong".
It seems you could easily distribute the load on multiple machines, each doing a subset of the regex.
There's something hilarious about having to distribute email filtering across several machines.
No; it's tragic that people reach for distributed, or "multi-core", whenever something runs too slowly. If filtering a mail according to a set of REs takes 15 seconds of CPU time like the OP writes, he's clearly doing something wrong, or hitting some limitation of procmail's design (being unable to amortize work, such as reading and parsing the REs, between mails).
Distributing wasteful work is not the right solution, in particular not if energy efficiency is a major concern like the OP suggests. (And I find it hard to believe that a 15s delay of mail delivery is his main concern!)
What would the database achieve?
Some people believe the solution to any problem involving data is a database
Fuck you and your RBLs. RBLs are a draconian solution that do immeasurable damage to those of us who (1) aren't spammers, and (2) choose to run our own mailservers on business-class IPs. [...]
Oh, because someone in the same
That sucks. And more generally, I believe the anti-spam fundamentalists have caused as much damage to the use of reliable mail, as the actual spammers. They are much too willing to accept collateral damage. Sad, when you consider how much effort went into designing (a) guaranteed delivery or (b) guaranteed notification of non-delivery.
For this particular situation: I accepted early on that many misconfigured mail servers "work" like you describe, so I make sure that my ISPs lets me relay via them.
I don't think there's any such thing as "pretty much finished",
There is; software designed according to "do one thing and do it well"
especially with a piece of software involved in the arms race that is spam vs. filtering.
... but yeah, well, I don't know Spamassassin but I suspect it has broader and more loosely-defined goals.
*Shrug* No. I don't like telling people what to do, and I suspect I'm not good at it. NB this doesn't mean I lack social skills. I can work with people; I just don't want to lead them.
Surely it's not hard to explain? It's how most people feel, after all.
Unless you're a Windows programmer, I'd stick with C, which is infinitely simpler, and provides you freedom to maintain competency in other languages,
Huh? So C++ somehow removes that freedom?
Let me also remind you that while C is simpler than C++, your C source code is more complex than your C++ code -- while doing the same things, using the same APIs and libraries. Personally, I am tired of implementing linked lists and hash tables for the Nth time and hunting for memory leaks and buffer overflows. Learning C++ was time well spent.
On the other hand, learning to use C is a good idea. It's the lingua franca in the Unix world at least.
many of which have far cooler features than C++ will ever be able to provide.
It is true that you're crippled if all you know is C++. Or C. Unsurprisingly, neither language is supposed to be the perfect tool for every job.
[C++] Talk about understanding value construction and destruction. And exception safety! Does anyone actually grok it to the degree that one doesn't need to think about it all the time?
I do. It's not hard. Not letting objects be in an invalid state in a context which expects them to be in a *valid* state is something that's important in any code in any language (except maybe functional languages?). C++ is not the problem here but part of the solution.
The why is so that you can take advantage of C++ features. Templates for example are a great way to write very fast code,
Fast code, sure, but the main use for C++ templates is to let you create sane, safe, readable and maintainable code. Or at least remove one of the obstacles for doing so.
Another issue is that some houses are not oriented well to collect sunlight. For example, a house with a single slopes roof that slopes toward the north would be an inefficient place to put solar panels.
That's why they're doing it in Peru, south of the Equator
Lots of people here saying "Don't use Adobe" and suggesting alternatives. Reality is, for many of us, we deal with complex PDF forms and applications that integrate directly with Adobe Acrobat. In my business [---] "Axis of Evil" of insecure software.
That seems like an accurate, believable description of a common situation. I just wish I'd some time see someone *try to get out* of a lock-in situation like that. Or try to avoid creating more such situations. It has been well-known for decades that you can end up there, and yet organizations still plunge in, head first, all the time.
(Note that the lock-in isn't just about paying $$$ to the vendor indefinitely. It also means your data is cut off from the rest of the ecosystem; you can't benefit from inventions done elsewhere. No version control for your MS Word documents, and so on.)
Work without a vision is slavery, Vision without work is a pipe dream, But vision with work is the hope of the world.
