Comment Re:Excellent point! (Score 2) 354
I have mod points
I have mod points
For that specific case, it does require SSH access.
However, SSH access is often used for protocols like git, which makes this rather problematic.
Additionally, the vulnerability is just as effective using the CGI variables via apache.
Yes. No. Wait - yes. No... no. Uh....
The systemd has modular design.
But monolithic architecture.
Literally everything inside systemd is intertwined using the D-Bus.
So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.
The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.
On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.
AFAICT, uselessd strips out everything that isn't part of init from systemd, including journald. So exactly which daemons are left that are intertwined with each other?
Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan.
Try reading the project site, because AFAICT it meets your requirements. They've removed pretty much everything except for init, including journald and udev.
Binding previously-separate features into one project is bad design, by itself, the problem with systemd.
Why? Justify that statement without using any reference to the UNIX way or it being the way things have always been designed.
IMHO a coordinated set of functions that are used in a common way should be combined.
There are times when combining separate features into a single project makes sense - BusyBox is the classic example of this.
The problem is that it reduces the system's modularity - instead of being able to replace udev, the logging interface, etc. independently, you need to replace/patch the entirety of systemd. Now, if the upstream was willing to actively support modularity by maintaining stable APIs, this wouldn't be a problem, but they've gone out of their way to remove those APIs from all the projects they've assimilated.
I think systemd offers significant improvements over its predecessors, and agree that journalctl is much easier to use, but I don't think the way the project is being managed is good for the long term health of the Linux ecosystem.
Agreed.
The real issue with systemd is that the vast majority of its development is funded by Red Hat. This means that while they claim systemd is modular, they don't accept any code that would actually facilitate that modularity by letting you replace udev with eudev, for example, because it's not useful to them and increases the maintenance burden.
Compare this to the kernel, which has deliberately been managed by a neutral party (the Linux Foundation) from the start. Can you imagine what the kernel would look like if it had been run by Red Hat, and only accepted code for kernel modules that were considered useful? My guess is we wouldn't have seen half the innovation we have, and things like btrfs wouldn't even exist.
The following is perfectly legal Haskell, and does exactly what it looks like:
x = 2 + 2 where 2 + 2 = 5
As such, both Intel and AMD have to work harder on backwards compatibility. I might buy new CPU when it goes on sale if I also don't have to upgrade motherboard and RAM.
Intel, ok, but AMD? AMD doesn't make breaking changes to their sockets unless they're needed to support newer memory. They released AM3 to support DDR3 in 2009, and AM3+ is backward compatible. (The FM sockets are for APUs only and therefore not relevant.)
In the same period, Intel has had 4 desktop sockets (twice as many as AMD), and none of which are backward compatible, AFAICT.
that war is over, and vi won
Vi's key feature was composability (you could use same motions with any action), and Emac's key feature was plugins.
Today, Vim has plenty of plugins (I have 48 in my vimrc as of yesterday), and Emacs
Vim won the way, but it became the enemy in the process.
It has nothing to do with "closed source." Show me what info is available when you do an "apt get upgrade".
Install apt-listchanges, and you can see the entire changelog.
I'm curious why you think that neither is better than the other.
I'm not familiar with Pascal, but as I understand it:
C strings are a series of characters, followed by a null terminator.
Pascal strings are a series of characters, prefixed by their length. If the implementation uses more than one word/byte to store the length, then you aren't limited to 255 characters.
Given how many security problems there have been in C programs due to incorrect handling of strings, the Pascal approach seems much safer (at the cost of a few additional bytes of memory per string, but I suspect each character is stored in its own word anyway for performance reasons).
The C++/D implementation seems to be the best so far though, since storing the length of the string with the pointer enables creation of substrings in constant time.
I like C# a lot. I wish people used it outside of Windows. Alas. I'll retire happy if I never touch Windows again, so C# is dead to me.
I'll second this. C# is a beautiful language with a terrible execution. Java is a terrible language with a much better execution (at least it has closures now...).
Having found myself in the same situation, you might want to take a look at D. It has very similar syntax to C#, but works just as well under Linux as Windows.
I think the main problem is that Linux is *TOO* configurable. "Normals" don't want hundreds of options. They want people to tell them which of a limited number of options will work for them.
Which distro should I pick? Which window manager should I pick? How do I configure my computer to be optimal for *ME*? I'm a techie and I can't tell you which distro is really the best for most people. I can tell you which ones are more stable.....but it isn't just ONE.
With Windows....and even Apple.....those choices are more or less made for you. All a "normal" needs to do is decide which apps they need to run and whether their OS supports those apps.
Being too configurable isn't a problem - needing to configure it is. Debian is about as configurable as Arch, but is significantly easier to use because it comes with a default configuration. You pick the most popular distro (Mint, according to distrowatch) and use whatever it comes with. Knowing how to customize it to suit you is something you learn over time, and is also completely unnecessary at the start of the learning curve.
The whole point of a distro is to make those choices for the user, while enabling varying degrees of customization. Choose the most popular distro, and you'll be fine.
I'm not the GP, but I thought I'd bite.
tldr; It's not perfect, but it's closer than you'd think.
D sounds like a neat language that I'll probably never be able to use. I'm a game developer, and C++ has a native compiler for every machine I would ever need my code to run on
DMD, LDC and GDC (the 3 most popular D compilers) work fine on x86 and x86_64.
LDC supports ARM and PowerPC with some issues. GDC apparently has better support for ARM
as well as an already mature ecosystem (engines, code libraries, sample code, all in C++).
D has very good interop support for C and C++ libraries. There's a significant number of wrapper libraries in dub as well.
In general, C code can be used as is, while C++ libraries often need a wrapper to work around issues like templates.
In fact, C/C++ is pretty much the only option I have if I want my code to be broadly portable.
Yes, C compilers exist for pretty much every architecture in existence, with C++ supported on most of them.
But this is a red herring, because the only instruction sets that really matter to someone in game development are x86, x86_64 and ARM. Whether or not you can compile your code for PIC is completely irrelevant. (That said, LDC uses LLVM for its backend, so it probably has the best chance of supporting unusual architectures.)
It's interesting how a lot of languages don't seem worry too much about backward compatibility, because they want to focus on a clean and better language. Unfortunately, in the real world, there are always massive amounts of legacy code that need to continue to work alongside whatever new whizbang features are introduced, even at the expense of a cleaner or more elegant language.
If I had to give any one reason for C++'s success, it would be the standards committee's stubborn (and in hindsight, wise) refusal to "clean up" the language by removing crufty features and syntax, a lot of which were leftover from C. C++ code from 20 years ago still compiles today mostly unchanged, and that's incredibly important when trying to build up or maintain a large ecosystem. You can see what a huge split it causes in the community when a language breaks compatibility like Python did (2.x vs 3.x), and ultimately, I wonder if it's more damaging than C++'s more conservative approach. As a developer, I'd be hesitant to heavily invest in a language that is more likely to break compatibility and leave me stranded.
Backward compatibility is always an issue with any piece of software. That said, I think there's something to be said for handling breaking changes well as opposed to handling them poorly - anything which creates a rift in the community is obviously an example of the latter.
Python was an example of the that, since it wasn't possible to combine code from old and new versions. While D had a breaking change with D2, there is only one person I am aware of who is still using D1. The standard library from D1 (Tango) was ported to D2, and the syntactic changes were fairly minor and easily remedied.
It's also worth noting that the D1 branch of DMD is still maintained, should you actually need to compile D1 code.
Pretty much every language is going to accumulate cruft over time. Even if D accumulates it at the same rate C++ did, it's relative youth means that it will be much more pleasant to work with, since C++ will always have more. I think the only real way to completely remove all that cruft is to create an entirely new language - no one would have complained about Python 3 if it were marketed as a new language, rather than as a new version with breaking changes (Nimrod is an example of this). This is what D is to C++ - a language with equivalent power that wipes the slate clean.
To put it simply, Kolab is a FOSS equivalent to Exchange. On the client side you can use Roundcube (a web UI), KDE Kontact, or anything supporting the IMAP-based protocol. It also supports ActiveSync for use with Android.
I set up Kolab 3.2 on a Debian a while back because I wanted a centralised calendar, etc. that didn't require me to trust Google with my life. It's worked pretty well, apart from a few issues. Configuration is a little tricky, especially as SSL is not the default and there are three different places it needs to be enabled. There are some minor bugs and instabilities, though hopefully they have been fixed in 3.3. Synchronization between the roundcube and IMAP clients can also be a little unreliable.
If anyone has any questions about it, I'll be happy to answer them.
One man's constant is another man's variable. -- A.J. Perlis
