Because every minor FireFox update gets to the/. front page.
Many people do not care. Most ex-FireFox users are still pissed that Mozilla has abandoned them. Throw in here Chrome users who dropped by to mock FireFox for being a copycat - and you have ideal mix for a minor flamewar.
You don't like something called 15?
You miss the point of software having the version number at all. FireFox version numbers are useless, because it is a rolling release strategy. And for example I personally do not like being an alpha tester for a piece of software which I use mostly for business purposes.
That is all you need to know from a version number.
Let me tell you an old story. Long long time ago, when Facebook was called MySpace and Google was still good, version numbers were also used to indicate stability of the software. E.g. version 2.2 was literally the same as version 2.1, but with less bugs. People could, for example, wait for software to stabilize sufficiently, for relevant bugs to be fixed, and then use it, expecting no nasty surprises at every possible turn.
Are mere mortals already allowed to use it? Last time I checked, they required some sort of registration.
Though from what I was reading up on it, the ESR doesn't make much sense: a random FireFox release is given the "ESR" moniker with purpose of providing only security fixes for it. If the random FireFox version happens to be totally borked and unusable, security fixes alone wouldn't help much.
The developers whining at the users with comments like "unless you're willing to write the replacement" doesn't help. Obviously, the developer isn't willing to write it either so we're at an impass.
It has been like that even before 2007. Tb management broke somewhere around first Mozilla milestones. I think the guy who was responsible (a.k.a.: had clue) for the Messenger development has left Netscape and that's when basically the end begun.
Later on, Mozilla has made the final stab at Tb and adopted the same management as for the Fx. Tb never recovered from it. And Mozilla still doesn't get the difference between a browser and a MUA.
Still remember one devel in a bug advising me as a workaround to delete my Tb profile and create it anew. After all - that works like charm for the Firefox!!
I have personally went through: Netscape Messenger/Tb, The Bat, Pegasus and Opera. But I have used them very very long time ago and can't attest to what they have developed into this days. Of all, I have used Netscape 4.x for the longest time and it was probably the best. Tb screw up many different things on way to simplify/dumbify the UI - probably SeaMonkey is slightly better, but I do not expect miracles. The Bat and Pegasus at the times didn't support neither HTML mail nor signing/encryption and were used for nothing serious. Opera... well I simply never liked the kinky UI of Opera and same goes for its e-mail program - powerful but slight odd and rough on edges - but many people like it.
Last stand alone client I have used (and liked) was KDE's KMail and it too was nothing serious. Overall, after struggling many time importing and reimporting my historical 2GB mbox I have completely abandoned desktop mail and now use exclusively (HTML-only version of) Google Mail (and in office I obliged to use the Outlook).
P.S. And, of course, there is always M$Outlook. My friend used it at home for many years.
I would have used iGoogle - and probably many others - if Google hadn't decided to f*ck up its appearance and behavior few years back. There were lots of flames on Google forums.
The iGoogle of 5-6 years ago was probably the best start page I ever had: fast loading, easy on eye design and most importantly useful.
The later iGoogle (with the unmovable bar on the left) looked like meh and some things also started behaving the same.
But it was all for the sake of the progress - as Google developers always tell us. And now they kill it.... LOL. They should restore from back-up the older version, make the "no more f*ck-ups" promise and I'm pretty sure many users would go back to using it.
P.S. I hope they wouldn't drop the old HTML-only GMail view. (Link to it they have already removed.) Or I would have to start looking for a new e-mail service too...
IIRC, the ELF is fat. The fatness is simply not used and deprecated.
But then again: fatness doesn't solve the problem - it just moves it around. In case of fat binaries the problem translates: some binaries are slim and not supporting all the expected architectures.
The problem, in general, is that for a single OS to have parallel support for multiple run-time architectures is messy and error prone.
Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
I should have spelled it out better: many pieces of software already now make a presumption what/usr/lib is: some insist that those must be 32bit libraries, some insist on the 64bit ones. LD_LIBRARY_PATH works most of the time - until you hit an application which to do its work launches other applications.
As for the headers... I have seen enough breakages to stop believing that #ifdefs are the solution: different software and different systems refer to the same thing with under names. Good luck finding a working combination. E.g. some functions are available in 32bit variant but not in 64bit variant, and vice versa. (That was recent fsck up of compiling VIM on the AIX 7: compile as 32bit, _XOPEN_SOURCE=600 - and it would fail linking because some 32bit libs are missing; try to compile as 64bit - only to find that _XOPEN_SOURCE wouldn't work and piles and piles of function declarations are missing. I had to hack the includes/defines into the config.h for the VIM to compile and link. (autoconf hasn't spotted it because it apparently couldn't imagine the functions missing.))
The negatives: * On a mixed x86-64 and X32 system, you have to load two copies of shared libraries (this doesn't happen with exclusively X32 systems).
It's not that the extra copies is the problem.
The problem is that you effectively have to have two different/usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the/usr/include. Compiling and running software occasionally becomes nightmarish experience.
After enjoying it thoroughly on the commercial *nix variants (Solaris and HP-UX), I have hopes that Linux will not do it and keep it clean: either fully 64bit system or fully 32bit system.
So you have never seen a Juniper router in action?
I did, but it was way too many years ago. The Juniper was huge and pretty dumb, but could route fiber gigabit in realtime.:)
That's essentially what they do, they take their routing table, lookup the MACs of the respective gateways on their ports and then generate a switch matrix which the routing component writes through to the switch.
Oh. So the SDN means: that above + standardized interface to install your own "plug-in" for the e.g. MAC resolution?
I had the (short) experience in the telecom and many years ago (I was told) it worked pretty much like that for PSTNs/etc. Also there I heard the terms "control plane" and "data plane" first time. I had this short employment where among other things I had to implement part of the "customer activation on first call" functionality: replace MAC with MSISDN, and it was pretty much the same thing you describe. Data plane of the switch (mostly hardware) was failing to "route" the record (and there were relatively few of them) and was forwarding it to control plane (mostly software) where it was decided what to do with it: allow it to be processed further or block. Based on that, switch configuration was updated with the new phone number and the action, and the record would be sent to data plane for reprocessing or dropped right away.
So it would seem that the old telecom paradigm has finally found a way into the corporate switches and routers.
P.S. The most recent official white paper on SDN turned out to be mostly marketing pep talk barren of technical details...
In the end you get a box which seems to run each layer at wire speed.
That, if data in the traffic do not change much. From the ONF site, the router has to consult with the software what to do with the unrecognized packet. That cannot be fast. What's more, unless they change order of packets, the router would have to stall the traffic on the port. If change of order is deemed acceptable, they can go on routing other packets, but in the mean time other packets requiring software introspection might come and they would have to be buffered. Buffering on router is bad, because later comes the problem of how to insert the now-cleared-for-delivery packets in the stream.
All in all, I do not see how even theoretically it can be "at wire speed": either lots of out of order packets with selectively long latencies or long stalls. More flexible and complicated you want it to be, more exotic cases you want to catch - the more overhead that would introduce.
N.B. considering potential amount of traffic going through a 16-port gigabit ethernet router, the forwarding of some share of the traffic to the remote software for introspection (and receiving responses from it) would potentially require duh 16 gigabit ethernet ports.
I'll go read the white papers, but it all looks pretty funny to me.
In some way this runs contrary to the Layer model, because you use higher level layers to just remap the Layer 2, but if you implement it transparently (e.g. the box looks correctly at each layer), it is just very fast without disturbing the layering.
Man, real networks pretty much never followed Layer model. It makes sense only on the paper. The likes of ARP and ICMP and DHCP fit the layer model only in mind of the most delusional. Networks were always built around RFC 1925, (1). Layer model is more of RFC 1925, (6a).
Actually, at least on laptops, the strongest association with the "Intel Inside" stickers is big ugly discolored spot on the laptop's surface left by attempts to remove it. Mind you, it is not as bad as the sore skin on a wrist due to constant rubbing on the sharp-edged "Windows Certified" sticker.
I still have around somewhere the first CD-Rs from around 1996-1998 filled with the MP3s of the music which was literally impossible to buy at the times. CD-R were rather expensive - but it was worth it. Cheap harddrives were already 2-4GB in size. For some of my friends, fans of death metal, the warez channels (P2P wasn't yet widespread enough) were pretty much only way to acquire some of the music (at good quality). Some of the world music and classical performances picked at the times I still can't find on CDs/better to this date.
And download speeds were not that bad either: you just queue stuff up in the evening and voila - next day morning it's finished! If something larger - leave it for the weekend. In a way, the Internet was faster in the times: I never had to wait for download to finish.:)
Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days.
On the positive side, if you know Linux, you have better chances of finding why the piece of software refuses to compile/link.
I'm no distro maintainer, but I do a share of platform porting. In my experience it is actually reliance on GCC (and prehistoric crap inside/usr/include/) which is more of a problem. Only after experiencing all that fun trying to compile open source software using non-GCC compilers (aCC, SunStudio, xlc), I have fully realized what kind of hurdle CLang developers and users have ahead of them.
How it is possible to not watch, when all social media are abuzz? All friends, colleagues are talking about it??
That's the whole point/problem of the current media model: they try to earn money by abusing part of human nature, which is to share an experience. That's also why the models are guaranteed to never last long: they are against the human nature.
Exploring a concept to assess feasibility can work, but don't expect to not have to nearly start over, just with the benefit of knowing which algorithms/development paths just won't pan out.
My problem with Perl is precisely that: it is nearly impossible (or very time consuming) to implement conventional data structures like list or tree in Perl. One generally doesn't need them in Perl - but they pop up pretty often in C/C++/etc.
Now, when prototype is implemented using the Perl's arrays and hashes, they are orthogonal to data structures C++ code it going to use. Assignment of arrays and hashes (even during their mutation in loop) is optimized well in Perl - but in C++, it would end up being a pretty dumb copy of large chunks of data. I see often the cases where prototype in Perl is managing task in fraction of second - while code dumbly 1:1 translated to C++ is taking seconds.
Thus IME even for potential algorithm assessment Perl is not a good choice. Algorithms as they are implemented in Perl and in C/C++ end up being way too different. In Perl it is easy to base many things on hashes and they would perform great. OTOH, if prototype is followed closely, in C++ one would be simply overwhelmed by the resulting code complexity of managing so many (potentially different) associative containers. Turning problem up side down and trying to implement prototype in Perl without hashes (I did this several times too) is a real chore and by complexity pretty close to implementing the same prototype in C++.
As it stands, I yet to find a language which is good for C/C++ prototyping. I have tried in past the Python, but was turned off by the lack of warnings and very poor performance. Lisp and some of its descendants theoretically are good candidates too, but I have none of them available in office.
Re:Like Perl, but Python dominates
on
Perl 5.16.0 Released
·
· Score: 3, Insightful
All they will use for scripting and prototyping is *Python*.
NOT using Perl for prototyping IME is a good thing.
Many of my program and libraries begin their life as proof-of-concept in Perl. And the problem is that from Perl implementation it is pretty much never possible to devise how much time it would take to implement C/C++/etc equivalent.
I had totally bad cases like where I have spent 2 weeks writing a library in C++ for which Perl's equivalent took me only 30 minutes. As a proof-of-concept, Perl implementation could be a quick hack - but C++ has to be a production quality. With the vast utility of Perl many corner cases seem trivial and work easily without performance regressions - while in C/C++ one ends up feeling like reimplementing the wheel for every one of them.
Perl is BAD for prototyping for C and C-like languages IMO. The difference between the languages and the libraries is way too great.
P.S. I'm not sure how better it is in Python. It should be better: the utility of the Python is much more limited compared to the Perl.
Google Reader "share" feature had a another, pretty unique feature: discussion/comments were flat and on the same level with the shared piece itself. One could see at once several shared pieces and friend comments. With G+ now that it is gone.
Another unique feature of the Google Reader was the relative non-bloated-ness of the view: you had the shared piece, you had friend comments, and there were no distractions.
Indeed Mozilla has become more like a company than an open source project.
Before Mozilla was an open source community.
Now it is literally corporation, sponsored pretty much exclusively by Google.
Before the project had to survive on the merit. Not anymore, and for as long as Google keeps writing them fat checks.
P.S. This is a rare moment when I regret about not collecting links to interesting materials I come across. The best and more insightful discussion on the topic was taking place on Debian mail lists in context of accepting corporate contributions especially when a corporation pays a Debian developer to work full time on the Debian.
I have old 20" which could be rotated. Yet. Widescreen monitors in vertical orientation are often not very stable and/or are heavy enough rock the table. At home my table isn't stable enough to support that and starts swaying when I type. In office I have better table, but the monitor there doesn't have VESA(?) mount. (And Iiyama (appear to be crappiest cheapest office 24"s our purchase could find) doesn't sell proper rotating stands for the line of monitors.)
Anyway, this is off-topic: I was complaining about laptops. I know my options with desktops and had chance to explore most of them. But. But one can NOT rotate laptop's screen.
Slashdot Mirror
Remind me again HOW MUCH YOU PAID FOR THIS FINE PRODUCT and then tell us more about your DEMANDS
I paid for it by seeing the Google Ads all over the internet.
You of course know that Mozilla is not community project anymore - it is bankrolled by Google?
Why are you whining?
Because every minor FireFox update gets to the /. front page.
Many people do not care. Most ex-FireFox users are still pissed that Mozilla has abandoned them. Throw in here Chrome users who dropped by to mock FireFox for being a copycat - and you have ideal mix for a minor flamewar.
You don't like something called 15?
You miss the point of software having the version number at all. FireFox version numbers are useless, because it is a rolling release strategy. And for example I personally do not like being an alpha tester for a piece of software which I use mostly for business purposes.
That is all you need to know from a version number.
Let me tell you an old story. Long long time ago, when Facebook was called MySpace and Google was still good, version numbers were also used to indicate stability of the software. E.g. version 2.2 was literally the same as version 2.1, but with less bugs. People could, for example, wait for software to stabilize sufficiently, for relevant bugs to be fixed, and then use it, expecting no nasty surprises at every possible turn.
Are mere mortals already allowed to use it? Last time I checked, they required some sort of registration.
Though from what I was reading up on it, the ESR doesn't make much sense: a random FireFox release is given the "ESR" moniker with purpose of providing only security fixes for it. If the random FireFox version happens to be totally borked and unusable, security fixes alone wouldn't help much.
The developers whining at the users with comments like "unless you're willing to write the replacement" doesn't help. Obviously, the developer isn't willing to write it either so we're at an impass.
It has been like that even before 2007. Tb management broke somewhere around first Mozilla milestones. I think the guy who was responsible (a.k.a.: had clue) for the Messenger development has left Netscape and that's when basically the end begun.
Later on, Mozilla has made the final stab at Tb and adopted the same management as for the Fx. Tb never recovered from it. And Mozilla still doesn't get the difference between a browser and a MUA.
Still remember one devel in a bug advising me as a workaround to delete my Tb profile and create it anew. After all - that works like charm for the Firefox!!
In Ex-USSR The Bat is quite popular.
My friend used for many years the Foxmail (but from the first glance I do not see where the English version is).
There are also of course Opera and Pegasus.
I have personally went through: Netscape Messenger/Tb, The Bat, Pegasus and Opera. But I have used them very very long time ago and can't attest to what they have developed into this days. Of all, I have used Netscape 4.x for the longest time and it was probably the best. Tb screw up many different things on way to simplify/dumbify the UI - probably SeaMonkey is slightly better, but I do not expect miracles. The Bat and Pegasus at the times didn't support neither HTML mail nor signing/encryption and were used for nothing serious. Opera ... well I simply never liked the kinky UI of Opera and same goes for its e-mail program - powerful but slight odd and rough on edges - but many people like it.
Last stand alone client I have used (and liked) was KDE's KMail and it too was nothing serious. Overall, after struggling many time importing and reimporting my historical 2GB mbox I have completely abandoned desktop mail and now use exclusively (HTML-only version of) Google Mail (and in office I obliged to use the Outlook).
P.S. And, of course, there is always M$Outlook. My friend used it at home for many years.
Anybody heard any reaction from the antitrust authorities?
US would probably remain mum, but I do not think EU would accept the OEM lockdown by convicted monopolist that readily.
Yes, there are security concerns, but they are negligible compared to the power grab by the convicted monopolist.
LOL
I would have used iGoogle - and probably many others - if Google hadn't decided to f*ck up its appearance and behavior few years back. There were lots of flames on Google forums.
The iGoogle of 5-6 years ago was probably the best start page I ever had: fast loading, easy on eye design and most importantly useful.
The later iGoogle (with the unmovable bar on the left) looked like meh and some things also started behaving the same.
But it was all for the sake of the progress - as Google developers always tell us. And now they kill it.... LOL. They should restore from back-up the older version, make the "no more f*ck-ups" promise and I'm pretty sure many users would go back to using it.
P.S. I hope they wouldn't drop the old HTML-only GMail view. (Link to it they have already removed.) Or I would have to start looking for a new e-mail service too...
IIRC, the ELF is fat. The fatness is simply not used and deprecated.
But then again: fatness doesn't solve the problem - it just moves it around. In case of fat binaries the problem translates: some binaries are slim and not supporting all the expected architectures.
The problem, in general, is that for a single OS to have parallel support for multiple run-time architectures is messy and error prone.
Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
I should have spelled it out better: many pieces of software already now make a presumption what /usr/lib is: some insist that those must be 32bit libraries, some insist on the 64bit ones. LD_LIBRARY_PATH works most of the time - until you hit an application which to do its work launches other applications.
As for the headers... I have seen enough breakages to stop believing that #ifdefs are the solution: different software and different systems refer to the same thing with under names. Good luck finding a working combination. E.g. some functions are available in 32bit variant but not in 64bit variant, and vice versa. (That was recent fsck up of compiling VIM on the AIX 7: compile as 32bit, _XOPEN_SOURCE=600 - and it would fail linking because some 32bit libs are missing; try to compile as 64bit - only to find that _XOPEN_SOURCE wouldn't work and piles and piles of function declarations are missing. I had to hack the includes/defines into the config.h for the VIM to compile and link. (autoconf hasn't spotted it because it apparently couldn't imagine the functions missing.))
Linux now is more or less clean of the madness.
The negatives:
* On a mixed x86-64 and X32 system, you have to load two copies of shared libraries (this doesn't happen with exclusively X32 systems).
It's not that the extra copies is the problem.
The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.
After enjoying it thoroughly on the commercial *nix variants (Solaris and HP-UX), I have hopes that Linux will not do it and keep it clean: either fully 64bit system or fully 32bit system.
Fork?
So you have never seen a Juniper router in action?
I did, but it was way too many years ago. The Juniper was huge and pretty dumb, but could route fiber gigabit in realtime. :)
That's essentially what they do, they take their routing table, lookup the MACs of the respective gateways on their ports and then generate a switch matrix which the routing component writes through to the switch.
Oh. So the SDN means: that above + standardized interface to install your own "plug-in" for the e.g. MAC resolution?
I had the (short) experience in the telecom and many years ago (I was told) it worked pretty much like that for PSTNs/etc. Also there I heard the terms "control plane" and "data plane" first time. I had this short employment where among other things I had to implement part of the "customer activation on first call" functionality: replace MAC with MSISDN, and it was pretty much the same thing you describe. Data plane of the switch (mostly hardware) was failing to "route" the record (and there were relatively few of them) and was forwarding it to control plane (mostly software) where it was decided what to do with it: allow it to be processed further or block. Based on that, switch configuration was updated with the new phone number and the action, and the record would be sent to data plane for reprocessing or dropped right away.
So it would seem that the old telecom paradigm has finally found a way into the corporate switches and routers.
P.S. The most recent official white paper on SDN turned out to be mostly marketing pep talk barren of technical details...
In the end you get a box which seems to run each layer at wire speed.
That, if data in the traffic do not change much. From the ONF site, the router has to consult with the software what to do with the unrecognized packet. That cannot be fast. What's more, unless they change order of packets, the router would have to stall the traffic on the port. If change of order is deemed acceptable, they can go on routing other packets, but in the mean time other packets requiring software introspection might come and they would have to be buffered. Buffering on router is bad, because later comes the problem of how to insert the now-cleared-for-delivery packets in the stream.
All in all, I do not see how even theoretically it can be "at wire speed": either lots of out of order packets with selectively long latencies or long stalls. More flexible and complicated you want it to be, more exotic cases you want to catch - the more overhead that would introduce.
N.B. considering potential amount of traffic going through a 16-port gigabit ethernet router, the forwarding of some share of the traffic to the remote software for introspection (and receiving responses from it) would potentially require duh 16 gigabit ethernet ports.
I'll go read the white papers, but it all looks pretty funny to me.
In some way this runs contrary to the Layer model, because you use higher level layers to just remap the Layer 2, but if you implement it transparently (e.g. the box looks correctly at each layer), it is just very fast without disturbing the layering.
Man, real networks pretty much never followed Layer model. It makes sense only on the paper. The likes of ARP and ICMP and DHCP fit the layer model only in mind of the most delusional. Networks were always built around RFC 1925, (1). Layer model is more of RFC 1925, (6a).
SPDY optimizes on a per-domain basis. In an extreme case where every resource is hosted on a different domain, SPDY doesn’t help.
So the whole CDN thing has to be redone for SPDY to deliver on the promises?
Actually, at least on laptops, the strongest association with the "Intel Inside" stickers is big ugly discolored spot on the laptop's surface left by attempts to remove it. Mind you, it is not as bad as the sore skin on a wrist due to constant rubbing on the sharp-edged "Windows Certified" sticker.
At best, an Intel phone will be no different than a ARM one, and at worst it will just add an extra bit of frustration.
You forget the "Intel Inside" stickers.
Promotional stickers is something mobile phones still sorely lacking.
You are sort'a right. But not really.
I still have around somewhere the first CD-Rs from around 1996-1998 filled with the MP3s of the music which was literally impossible to buy at the times. CD-R were rather expensive - but it was worth it. Cheap harddrives were already 2-4GB in size. For some of my friends, fans of death metal, the warez channels (P2P wasn't yet widespread enough) were pretty much only way to acquire some of the music (at good quality). Some of the world music and classical performances picked at the times I still can't find on CDs/better to this date.
And download speeds were not that bad either: you just queue stuff up in the evening and voila - next day morning it's finished! If something larger - leave it for the weekend. In a way, the Internet was faster in the times: I never had to wait for download to finish. :)
Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days.
On the positive side, if you know Linux, you have better chances of finding why the piece of software refuses to compile/link.
I'm no distro maintainer, but I do a share of platform porting. In my experience it is actually reliance on GCC (and prehistoric crap inside /usr/include/) which is more of a problem. Only after experiencing all that fun trying to compile open source software using non-GCC compilers (aCC, SunStudio, xlc), I have fully realized what kind of hurdle CLang developers and users have ahead of them.
How it is possible to not watch, when all social media are abuzz? All friends, colleagues are talking about it??
That's the whole point/problem of the current media model: they try to earn money by abusing part of human nature, which is to share an experience. That's also why the models are guaranteed to never last long: they are against the human nature.
Exploring a concept to assess feasibility can work, but don't expect to not have to nearly start over, just with the benefit of knowing which algorithms/development paths just won't pan out.
My problem with Perl is precisely that: it is nearly impossible (or very time consuming) to implement conventional data structures like list or tree in Perl. One generally doesn't need them in Perl - but they pop up pretty often in C/C++/etc.
Now, when prototype is implemented using the Perl's arrays and hashes, they are orthogonal to data structures C++ code it going to use. Assignment of arrays and hashes (even during their mutation in loop) is optimized well in Perl - but in C++, it would end up being a pretty dumb copy of large chunks of data. I see often the cases where prototype in Perl is managing task in fraction of second - while code dumbly 1:1 translated to C++ is taking seconds.
Thus IME even for potential algorithm assessment Perl is not a good choice. Algorithms as they are implemented in Perl and in C/C++ end up being way too different. In Perl it is easy to base many things on hashes and they would perform great. OTOH, if prototype is followed closely, in C++ one would be simply overwhelmed by the resulting code complexity of managing so many (potentially different) associative containers. Turning problem up side down and trying to implement prototype in Perl without hashes (I did this several times too) is a real chore and by complexity pretty close to implementing the same prototype in C++.
As it stands, I yet to find a language which is good for C/C++ prototyping. I have tried in past the Python, but was turned off by the lack of warnings and very poor performance. Lisp and some of its descendants theoretically are good candidates too, but I have none of them available in office.
All they will use for scripting and prototyping is *Python*.
NOT using Perl for prototyping IME is a good thing.
Many of my program and libraries begin their life as proof-of-concept in Perl. And the problem is that from Perl implementation it is pretty much never possible to devise how much time it would take to implement C/C++/etc equivalent.
I had totally bad cases like where I have spent 2 weeks writing a library in C++ for which Perl's equivalent took me only 30 minutes. As a proof-of-concept, Perl implementation could be a quick hack - but C++ has to be a production quality. With the vast utility of Perl many corner cases seem trivial and work easily without performance regressions - while in C/C++ one ends up feeling like reimplementing the wheel for every one of them.
Perl is BAD for prototyping for C and C-like languages IMO. The difference between the languages and the libraries is way too great.
P.S. I'm not sure how better it is in Python. It should be better: the utility of the Python is much more limited compared to the Perl.
and i don't know of any good alternatives.
I have checked this thoroughly: there are none.
Essentially, all the social networks are made simple and uniform so that even an idiot can use them.
Google Reader "share" feature had a another, pretty unique feature: discussion/comments were flat and on the same level with the shared piece itself. One could see at once several shared pieces and friend comments. With G+ now that it is gone.
Another unique feature of the Google Reader was the relative non-bloated-ness of the view: you had the shared piece, you had friend comments, and there were no distractions.
Indeed Mozilla has become more like a company than an open source project.
Before Mozilla was an open source community.
Now it is literally corporation, sponsored pretty much exclusively by Google.
Before the project had to survive on the merit. Not anymore, and for as long as Google keeps writing them fat checks.
P.S. This is a rare moment when I regret about not collecting links to interesting materials I come across. The best and more insightful discussion on the topic was taking place on Debian mail lists in context of accepting corporate contributions especially when a corporation pays a Debian developer to work full time on the Debian.
I have old 20" which could be rotated. Yet. Widescreen monitors in vertical orientation are often not very stable and/or are heavy enough rock the table. At home my table isn't stable enough to support that and starts swaying when I type. In office I have better table, but the monitor there doesn't have VESA(?) mount. (And Iiyama (appear to be crappiest cheapest office 24"s our purchase could find) doesn't sell proper rotating stands for the line of monitors.)
Anyway, this is off-topic: I was complaining about laptops. I know my options with desktops and had chance to explore most of them. But. But one can NOT rotate laptop's screen.