The problem with it is that with Windows you are pretty much forced to buy such solution, either from MS or from 3rd parties.
With Linux, it is really an option, a "nice to have".
For example, a small engineering company in Germany. They actually bought it for 12 desktops in their office. (One desktop is actually server.) Not because they had to, but because it basically freed them up from having a full time admin. (They have admin, but he wanted to go into the CAD/design, and the Ubuntu managed solution simply allowed him to.) (Why Ubuntu? They have tried it - it worked for them well and they have stayed with it.)
LANG=Japanese appname in the terminal makes so much more sense.
The problem with that, is that very few applications are now isolated these days. You typically have a DB back-end, data export/import and RPC to other system services. Setting a different locale is error prone since some data might be simply misinterpreted and end up corrupted. And that is real problem, since lots of user data are actually stored in textual form (even in DB!).
IME, the per-application locale has its uses, but in real world it causes more problems than it solves. In fact, since most Linux distros support quick account switching, the cheapest solution right now is to use two accounts with different locales.
Forcing systemwide language settings is a broken concept. The fact my Japanese wife has to set her whole iphone to English to get google maps to say street names in the US while driving is a great real world example.
There is no sane way to solve that problem on the level of OS. (Even "primary language; secondary language" is not enough, since for example I have to deal daily with three languages (Russian, English, German).) Most of the time this ends up being in the responsibility of the application developers: if they care enough, they offer a possibility to use a language different from the system one.
Think of the flip-side: you might accidentally force all Japanese and all English iPhones to download both English and Japanese locale data. And this is pretty large amount of the data to just sit around idly, just in case when user might once decide to hear the street names in different language.
For example, you change time zone or locale in system settings and your organizer app automatically picks up the changes.
And if the services do not depend on systemd, why are they part of the package?
Pottering is maintainer of all of them. So he brought it under the systemd umbrella.
Sounds like a made-up scenario and some bad packaging. Not a real-world need.
Applications "need" the services. They do not care who provides the services. As was said many times, the daemons - with few irrelevant changes to the source code to remove hardcoded systemd depedency - run fine without systemd.
Certainly fits the systemd reputation for taking over already-solved problems without any reason, though.
Yes.
Pottering also enjoys the confusion he has seeded with the organization of the systemd. He claims simultaneously (depending on the context; and to his advantage) that systemd is modular and monolithic. While in fact systemd has monolithic architecture and modular design. Pretty much the worst combination possible - prominently featured in the MSWindows, why comparison with Windows is highly relevant. (Ideally you want modular architecture, while design could be either monolithic (e.g. Linux kernel, optimized for performance) or modular (e.g. GIMP with the tons of the plug-ins, geared toward extensibility). But monolithic architecture is pretty much the worst thing you could ever do to a software project.)
For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
For applications. To handle properly when user changes the system settings.
These daemons are primitive at best. There were more comments written about them then there is source code lines in them.
Note, I'm in no favor of systemd itself. Debian in the past exemplified that you can actually use GNOME on a system without systemd, with only slightly patched up systemd-*d daemons. Which makes a lot of sense to me. But their maintainer is Poeterring, and he merged that all into the systemd, and there is no replacement for the daemons, so...
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones.
Nobody dismisses the multi-user-ness of the *NIX. In fact, the services should improve that by allowing a user to easily change his own locale/time zone without the need for log-out/log-in cycle.
The blank the services are filling is allowing application to perform application-specific tasks *when* user changes the locale or time zone. Editing a text config, and then restarting everything is, sorry, but horribly outdated. (We can update kernel on the fly - but not locale!? WTF?)
The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
The systemd-timedated does almost the same for the date and time.
And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.
What any of that has to do with the network time protocol?
FreeBSD folks do the same thing Debian did for some time before adopting the systemd: instead of the systemd, provide the teeny-tiny services, applications actually depend on.
[...] comes from the tried and true cycle of hypothesis --> test --> evaluate.
Ah. The science. The scientific process. But science is precisely the example of the branch with closed environment, discrimination and elitism, which abhors and rejects any innovation or change. Unless it comes from a prof with a fat grant, of course.
That's why, for example, computer science, effectively branched off and doesn't use the scientific process. Likewise, most of the industries: the scientific process is way too expensive and way too wasteful when applied to tangible things. Some areas do it because all low hanging fruits are already gone and there is simply no alternative. But again, due to the costs, it is applied in a very very limited fashion.
In the end, in this particular context, it is OK to ignore science because your definition of innovation is simply different. Heck, you measure "innovation" in number of published papers.
That's an appealing idea, but I don't think it's true. I've read before that innovation generally comes from the experts in a field and the "happy accident" type of innovation from naive newcomers is more myth than reality.
Not in my experience, though.
But of course professional pride kicks in even before the first round of applause fades, and after that it is "of course it was very very hard work!!!"
Then again, I probably define innovation very differently than someone focused on an incubator village and start-ups. I'm thinking more along the lines of Bell Labs [...]
That's precisely the type of innovation I was talking about. (Facebook thingies happen by throwing stuff against the wall and seeing what sticks. When lots of people do it simultaneously, there is a chance that some of it sticks.)
The thing about big R&D centers is that nobody really sees what's going on behind the closed doors. Behind the closed doors in the most "productive" labs you would find chaos and disorder - precisely the environment where errors and accidents occur. But it certainly takes dedication (to field or problem) to actually make out of that a "Eureka!" moment.
Otherwise, if innovation was that easy to achieve by simply good planning, then it would have been done a long time ago.
I'm clearly a beardy type despite cutting my teeth on Unix well after 1988. Apparently I did get the message where so many others did not.
I started seriously with Linux in 1999, after 5 years of WinNT4. And I do not like the systemd.
SystemD is a reinvention of Windows for Linux. It's even made the same way as the Windows: modular design with monolitic architecture. Just like a card house: pull one card, and the whole thing comes down.
That's why Linux back then was like a breath of fresh air to me. Coming from NT4 (which was hard to keep working) to Linux (which I could bring back from a fatal failure in under 15 minutes) pretty much exemplified to me how *NOT* to design the software.
SystemD is indeed the "second system effect" which (unknowingly?) implements many errors of the Windows. The errors which still hunt MS to this day!. (E.g. all embedded Windows attempts failed. Now they have a dedicated embedded system - WinPho - because porting the "card house" to another device built around different paradigms is hard and costly and error prone. It works like crap in the end, while providing no benefits to developers (making portable applications proved to be futile; with WinPho MS stopped promising it) and consequently users.)
... I come down on the systemd side when I want my laptop to correctly connect to the appropriate WiFi network (but only if not connected to a wired network).
The NetworkManager is written by literally the same people who work on the SystemD.
If it hadn't worked before, why you think it would work afterwards?
Not so rare if (A) you have full assortment of the.Net run-times installed and (B) skip some monthly update.
At the worst, on my Win7 I had about 5.Net run-times installed. It happened more than once that after one dot-point update, there was another dot-point update immediately available.
(Plus, there were two "uninstallable".net updates: they would silently fail to install and after reboot you would be asked to update again to the same version. I see that shit because I have auto-updates disabled. But for normal people with auto-updates on, that would be a prompt to reboot ~30 min after previous reboot.)
The only solution is to uninstall the application which requires the uncommon.net version and uninstall the redundant.net run-times.
Debian IIRC would ask you ~3 times (displaying big scary warnings that you better know what you are doing and Debian isn't responsible for the consequences of your actions) before it would let you uninstall a core OS package like glibc or text-tools or perl.
That is also reason why Debian rebuilds the initrd so often, seemingly redundantly, during the update. To make sure that even if system went down during the update, and there are updated kernel modules, chances are great that your system would remain in a bootable state.
The traditional problems of the RedHat systems where RPM lets you screw your system (or screws it on its own automatically; or refuses to do a trivial thing, you force it and it conveniently screws it for you) at least to me are long over.
Well, actually, it does. Because Android to be useable requires Google account. And when you create a Google account, Google conveniently activate the "Sync", IOW, sending your contacts, appointments, messages, etc - for archive purposed - to the Google servers.
and not without permission and it is *not* acceptable.
Buried in the EULA is not the same as giving an explicit permission. Having a crippled brick instead of the phone serves is a good incentive to "give the permission" to be spied on.
As others have said: do not put any sensitive information on the phone. IMO, with the current business around private information, masquerading as the "social" networking, I wouldn't even put the encrypted files on the smartphones.
"We saw that on startup, the phone sent the telco name to the server api.account.xiaomi.com. It also sent IMEI and phone number to the same server," F-Secure said.
When my Android phone starts, I'm pretty sure it sends the same shit to api.account.google.com or some such. And probably to api.account.samsung.com. Because I have Google and Samsung accounts and I'm logged in by default.
Has the F-Secure tried to, as article mentions, disable the Mi Cloud account? Probably not. Because it wouldn't have been in the news then.
When news comes from "security" consultancies, I frankly often side with the manufacturers. The ensuing hype only promotes the "consultancies" - and does nothing positive for the manufacturers. Why would they (manufacturers) add something to the phone to help promote the "consultancies"?!
When asking around for my WRT54G, not once I got advise that the only router matching the stability is the Apple AirPort.
Then you need to change the people you are asking or at least enlarge it to people beyond those who's biggest joy is hacking access points.
I had to exclude this category of people, because to many of them router reboots is a daily routine.
Just like that I had almost purchased the brand new Asus AC66U(?). A person on forums praised every feature, general performance and stability. But in later comments just casually dropped that if you use wi-fi for longer than two hours continuously, wireless dies and router autoreboots. But that's totally OK, because he uses it for movie streaming and a rare movie is two hours long! Bonus: the router is freshly started!! (No, I'm not making it up.)
When all is equal, I'd rather pick the device that Just Works(tm) than the one I can tweak to no end, but it fails periodically.
WRT54G is well known for its stability and reliability.
I bet half of the routers on the "supported devices" lists wouldn't even manage the wi-fi ping test: simply ping the router for several hours. The junk hardware would overheat and reboot. The "better" would only reset the wireless, killing other connections in the process.
Only few devices actually manage to survive pretty normal traffic pattern of power users: whole day of streaming movies and music over wireless plus some P2P traffic over wired, some of it potentially wrapped up in some VPN. The quest is to find the devices, which are (1) proven to work and (2) still sold.
When asking around for my WRT54G, not once I got advise that the only router matching the stability is the Apple AirPort. They are more expensive, comparatively limited in function - but whatever traffic you throw at it, however long, just like the WRT54G, it simply handles it without outages.
I was also looking at the Asus RT-N66 series, the second top rated advise I got, but they still have stability problems if you overload them. And not all devices/revisions are compatible to tomato/open-wrt/etc too.
Otherwise, most routers are still suspect to the overhead + auto-reboot cycles. Not mentions the long-term Wi-Fi transfer problems. Pretty sad state of the affairs, really.
This is probably the most unjustified complain you throw. The tags support in VIM is very good - if you bothered to RTFM. Literally every book and tutorial describe these highly sophisticated and inexplicable 3 steps involved: install the exuberant ctags, put into the.vimrc the line ":set tags=tags;/", and finally run "ctags -R." in the root of the project.
Problem is not VIM, it is the ctags. Ctags just doesn't work - good enough for me. I have used it, and it just goes berserk with #defines, files which are not.h or.c (xml rules or binary blobs, etc.).
Yes. But this is more of the problem with the programming language itself. Or better: practices, the project uses.
For example, in my current project, ctags and Eclipse both do excellent job of indexing the 100% C code base. Because there are actually strict guidelines relating the preprocessor and code formatting. In my previous project, a C++ one, the hacks had used macro definition (and redefinitions) not only for the class names, but also for the namespaces, including the "using" clause. No indexer could ever parse it and some classes and functions were never visible in the index.
In the end, I found that for as long as I can read and understand the code on first look, so can the indexer. If one writes a quirky hairy mess, then indexer probably is not even the biggest issue.
Slashdot Mirror
Where's the fun in using something that just works?!
I think "simplifying" would only cause lots of pain.
KDE is already pretty well structured. What they need to do is to simply develop a new "front-end" for all the back-end goodies.
And why stop there - make a framework so that almost anybody can easily experiment with front-end development.
That would be, IMO, the most KDE-ish way to do it. Everything else would lead to the debacle like the KDE3 vs. KDE4 was.
We heard this argument many times before.
The problem with it is that with Windows you are pretty much forced to buy such solution, either from MS or from 3rd parties.
With Linux, it is really an option, a "nice to have".
For example, a small engineering company in Germany. They actually bought it for 12 desktops in their office. (One desktop is actually server.) Not because they had to, but because it basically freed them up from having a full time admin. (They have admin, but he wanted to go into the CAD/design, and the Ubuntu managed solution simply allowed him to.) (Why Ubuntu? They have tried it - it worked for them well and they have stayed with it.)
LANG=Japanese appname in the terminal makes so much more sense.
The problem with that, is that very few applications are now isolated these days. You typically have a DB back-end, data export/import and RPC to other system services. Setting a different locale is error prone since some data might be simply misinterpreted and end up corrupted. And that is real problem, since lots of user data are actually stored in textual form (even in DB!).
IME, the per-application locale has its uses, but in real world it causes more problems than it solves. In fact, since most Linux distros support quick account switching, the cheapest solution right now is to use two accounts with different locales.
Forcing systemwide language settings is a broken concept. The fact my Japanese wife has to set her whole iphone to English to get google maps to say street names in the US while driving is a great real world example.
There is no sane way to solve that problem on the level of OS. (Even "primary language; secondary language" is not enough, since for example I have to deal daily with three languages (Russian, English, German).) Most of the time this ends up being in the responsibility of the application developers: if they care enough, they offer a possibility to use a language different from the system one.
Think of the flip-side: you might accidentally force all Japanese and all English iPhones to download both English and Japanese locale data. And this is pretty large amount of the data to just sit around idly, just in case when user might once decide to hear the street names in different language.
Wait, who actually needs to do those things?
Desktop applications.
For example, you change time zone or locale in system settings and your organizer app automatically picks up the changes.
And if the services do not depend on systemd, why are they part of the package?
Pottering is maintainer of all of them. So he brought it under the systemd umbrella.
Sounds like a made-up scenario and some bad packaging. Not a real-world need.
Applications "need" the services. They do not care who provides the services. As was said many times, the daemons - with few irrelevant changes to the source code to remove hardcoded systemd depedency - run fine without systemd.
Certainly fits the systemd reputation for taking over already-solved problems without any reason, though.
Yes.
Pottering also enjoys the confusion he has seeded with the organization of the systemd. He claims simultaneously (depending on the context; and to his advantage) that systemd is modular and monolithic. While in fact systemd has monolithic architecture and modular design. Pretty much the worst combination possible - prominently featured in the MSWindows, why comparison with Windows is highly relevant. (Ideally you want modular architecture, while design could be either monolithic (e.g. Linux kernel, optimized for performance) or modular (e.g. GIMP with the tons of the plug-ins, geared toward extensibility). But monolithic architecture is pretty much the worst thing you could ever do to a software project.)
The three services are actually needed.
For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
For applications. To handle properly when user changes the system settings.
These daemons are primitive at best. There were more comments written about them then there is source code lines in them.
Note, I'm in no favor of systemd itself. Debian in the past exemplified that you can actually use GNOME on a system without systemd, with only slightly patched up systemd-*d daemons. Which makes a lot of sense to me. But their maintainer is Poeterring, and he merged that all into the systemd, and there is no replacement for the daemons, so...
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones.
Nobody dismisses the multi-user-ness of the *NIX. In fact, the services should improve that by allowing a user to easily change his own locale/time zone without the need for log-out/log-in cycle.
The blank the services are filling is allowing application to perform application-specific tasks *when* user changes the locale or time zone. Editing a text config, and then restarting everything is, sorry, but horribly outdated. (We can update kernel on the fly - but not locale!? WTF?)
See previous reply to my comment.
The systemd-timedated is harmless - the systemd-timesyncd is a different story.
So the rumors were true that in V2.0 systemd would finally offer integration with ntoskrnl.exe, along with rewrite to take full advantages of the CLR.
The three services are actually needed.
The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
The systemd-timedated does almost the same for the date and time.
And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.
What any of that has to do with the network time protocol?
FreeBSD folks do the same thing Debian did for some time before adopting the systemd: instead of the systemd, provide the teeny-tiny services, applications actually depend on.
[...] comes from the tried and true cycle of hypothesis --> test --> evaluate.
Ah. The science. The scientific process. But science is precisely the example of the branch with closed environment, discrimination and elitism, which abhors and rejects any innovation or change. Unless it comes from a prof with a fat grant, of course.
That's why, for example, computer science, effectively branched off and doesn't use the scientific process. Likewise, most of the industries: the scientific process is way too expensive and way too wasteful when applied to tangible things. Some areas do it because all low hanging fruits are already gone and there is simply no alternative. But again, due to the costs, it is applied in a very very limited fashion.
In the end, in this particular context, it is OK to ignore science because your definition of innovation is simply different. Heck, you measure "innovation" in number of published papers.
That's an appealing idea, but I don't think it's true. I've read before that innovation generally comes from the experts in a field and the "happy accident" type of innovation from naive newcomers is more myth than reality.
Not in my experience, though.
But of course professional pride kicks in even before the first round of applause fades, and after that it is "of course it was very very hard work!!!"
Then again, I probably define innovation very differently than someone focused on an incubator village and start-ups. I'm thinking more along the lines of Bell Labs [...]
That's precisely the type of innovation I was talking about. (Facebook thingies happen by throwing stuff against the wall and seeing what sticks. When lots of people do it simultaneously, there is a chance that some of it sticks.)
The thing about big R&D centers is that nobody really sees what's going on behind the closed doors. Behind the closed doors in the most "productive" labs you would find chaos and disorder - precisely the environment where errors and accidents occur. But it certainly takes dedication (to field or problem) to actually make out of that a "Eureka!" moment.
Otherwise, if innovation was that easy to achieve by simply good planning, then it would have been done a long time ago.
Except that you would rarely see new people.
More innovation happens by accidents, mistakes and misunderstandings. Or the ever silly questions of the newcomers.
Without inflow of new people, the "village" would suffer mental rot pretty quickly.
In a sense, a maker fairs are already better "startup villages", IMO.
I'm clearly a beardy type despite cutting my teeth on Unix well after 1988. Apparently I did get the message where so many others did not.
I started seriously with Linux in 1999, after 5 years of WinNT4. And I do not like the systemd.
SystemD is a reinvention of Windows for Linux. It's even made the same way as the Windows: modular design with monolitic architecture. Just like a card house: pull one card, and the whole thing comes down.
That's why Linux back then was like a breath of fresh air to me. Coming from NT4 (which was hard to keep working) to Linux (which I could bring back from a fatal failure in under 15 minutes) pretty much exemplified to me how *NOT* to design the software.
SystemD is indeed the "second system effect" which (unknowingly?) implements many errors of the Windows. The errors which still hunt MS to this day!. (E.g. all embedded Windows attempts failed. Now they have a dedicated embedded system - WinPho - because porting the "card house" to another device built around different paradigms is hard and costly and error prone. It works like crap in the end, while providing no benefits to developers (making portable applications proved to be futile; with WinPho MS stopped promising it) and consequently users.)
... I come down on the systemd side when I want my laptop to correctly connect to the appropriate WiFi network (but only if not connected to a wired network).
The NetworkManager is written by literally the same people who work on the SystemD.
If it hadn't worked before, why you think it would work afterwards?
Not so rare if (A) you have full assortment of the .Net run-times installed and (B) skip some monthly update.
At the worst, on my Win7 I had about 5 .Net run-times installed. It happened more than once that after one dot-point update, there was another dot-point update immediately available.
(Plus, there were two "uninstallable" .net updates: they would silently fail to install and after reboot you would be asked to update again to the same version. I see that shit because I have auto-updates disabled. But for normal people with auto-updates on, that would be a prompt to reboot ~30 min after previous reboot.)
The only solution is to uninstall the application which requires the uncommon .net version and uninstall the redundant .net run-times.
On Debian based systems this was never a problem.
Debian IIRC would ask you ~3 times (displaying big scary warnings that you better know what you are doing and Debian isn't responsible for the consequences of your actions) before it would let you uninstall a core OS package like glibc or text-tools or perl.
That is also reason why Debian rebuilds the initrd so often, seemingly redundantly, during the update. To make sure that even if system went down during the update, and there are updated kernel modules, chances are great that your system would remain in a bootable state.
The traditional problems of the RedHat systems where RPM lets you screw your system (or screws it on its own automatically; or refuses to do a trivial thing, you force it and it conveniently screws it for you) at least to me are long over.
Xiaomi MiPad
Wow. A 4:3 aspect ratio?
Do they per chance also have matte/non-glossy screens?
Mi Cloud is turned off, [...]
Oops! (Though I'm still doubtful, frankly.)
Your Android handset certainly does not do this,
Well, actually, it does. Because Android to be useable requires Google account. And when you create a Google account, Google conveniently activate the "Sync", IOW, sending your contacts, appointments, messages, etc - for archive purposed - to the Google servers.
and not without permission and it is *not* acceptable.
Buried in the EULA is not the same as giving an explicit permission. Having a crippled brick instead of the phone serves is a good incentive to "give the permission" to be spied on.
As others have said: do not put any sensitive information on the phone. IMO, with the current business around private information, masquerading as the "social" networking, I wouldn't even put the encrypted files on the smartphones.
"We saw that on startup, the phone sent the telco name to the server api.account.xiaomi.com. It also sent IMEI and phone number to the same server," F-Secure said.
When my Android phone starts, I'm pretty sure it sends the same shit to api.account.google.com or some such. And probably to api.account.samsung.com. Because I have Google and Samsung accounts and I'm logged in by default.
Has the F-Secure tried to, as article mentions, disable the Mi Cloud account? Probably not. Because it wouldn't have been in the news then.
When news comes from "security" consultancies, I frankly often side with the manufacturers. The ensuing hype only promotes the "consultancies" - and does nothing positive for the manufacturers. Why would they (manufacturers) add something to the phone to help promote the "consultancies"?!
When asking around for my WRT54G, not once I got advise that the only router matching the stability is the Apple AirPort.
Then you need to change the people you are asking or at least enlarge it to people beyond those who's biggest joy is hacking access points.
I had to exclude this category of people, because to many of them router reboots is a daily routine.
Just like that I had almost purchased the brand new Asus AC66U(?). A person on forums praised every feature, general performance and stability. But in later comments just casually dropped that if you use wi-fi for longer than two hours continuously, wireless dies and router autoreboots. But that's totally OK, because he uses it for movie streaming and a rare movie is two hours long! Bonus: the router is freshly started!! (No, I'm not making it up.)
When all is equal, I'd rather pick the device that Just Works(tm) than the one I can tweak to no end, but it fails periodically.
That's only half of it. And lesser at that.
WRT54G is well known for its stability and reliability.
I bet half of the routers on the "supported devices" lists wouldn't even manage the wi-fi ping test: simply ping the router for several hours. The junk hardware would overheat and reboot. The "better" would only reset the wireless, killing other connections in the process.
Only few devices actually manage to survive pretty normal traffic pattern of power users: whole day of streaming movies and music over wireless plus some P2P traffic over wired, some of it potentially wrapped up in some VPN. The quest is to find the devices, which are (1) proven to work and (2) still sold.
Doesn't sound like it.
When asking around for my WRT54G, not once I got advise that the only router matching the stability is the Apple AirPort. They are more expensive, comparatively limited in function - but whatever traffic you throw at it, however long, just like the WRT54G, it simply handles it without outages.
I was also looking at the Asus RT-N66 series, the second top rated advise I got, but they still have stability problems if you overload them. And not all devices/revisions are compatible to tomato/open-wrt/etc too.
Otherwise, most routers are still suspect to the overhead + auto-reboot cycles. Not mentions the long-term Wi-Fi transfer problems. Pretty sad state of the affairs, really.
This is probably the most unjustified complain you throw. The tags support in VIM is very good - if you bothered to RTFM. Literally every book and tutorial describe these highly sophisticated and inexplicable 3 steps involved: install the exuberant ctags, put into the .vimrc the line ":set tags=tags;/", and finally run "ctags -R ." in the root of the project.
Problem is not VIM, it is the ctags. Ctags just doesn't work - good enough for me. I have used it, and it just goes berserk with #defines, files which are not .h or .c (xml rules or binary blobs, etc.).
Yes. But this is more of the problem with the programming language itself. Or better: practices, the project uses.
For example, in my current project, ctags and Eclipse both do excellent job of indexing the 100% C code base. Because there are actually strict guidelines relating the preprocessor and code formatting. In my previous project, a C++ one, the hacks had used macro definition (and redefinitions) not only for the class names, but also for the namespaces, including the "using" clause. No indexer could ever parse it and some classes and functions were never visible in the index.
In the end, I found that for as long as I can read and understand the code on first look, so can the indexer. If one writes a quirky hairy mess, then indexer probably is not even the biggest issue.
That's probably why they have leaked it.
Now they use the court case to both play innocent and maintain presence in the news.
It's a win-win for them.