While I haven't RTFA yet, I find the premise stated in the posting somewhat far-fetched. If I need binaries tuned finer than those provided by binary.rpm's, I can take their respective.src.rpm's and rebuild them. The RPM build system, in the distributions I know, provides a convenient way to override optimization flags via system- or user-settable macros. As for compilation time, it's not an issue for most packages these days, as many Gentoo users here can testify.
All these fancy formats: 192kHz, 24 bits, everything is perfect, until you plug your DVD-A, SACD player to your stereo, that has a 44kHz, 16 bit DSP for equalizing sound...
My soundcard is capable of 6 channels 24bit/96kHz and is quite affordable. These days 7.1 24bit/192kHz is no uber-equipment either.
By moving I meant relocating to Moscow, St.Petersburg, Novosibirsk, or other big city that has the software industry going. This is not entirely impossible. Leaving the country is still an option too, as you mention. Anyway, there is always a choice.
The counterparts of many American geeks in Russia couldn't find a well paying job Yeah, cry me a river. At least in major sities, this is not the case. The definition of "well paying" may vary, but we're talking about Russian standards here. It's more like the employers can't find adequate geeks to man the jobs. In small shitholes, it can be tougher (what country has it the other way?). But nothing really prevents people from moving anymore. The bottom line is: these people have deliberately chosen to be scumbags.
They made me feel pretty stupid for asking. Recalling one spectacular $1e8-figure failure somewhere in the Solar System, I think it's sometimes better to ask.
Even the Estonian government has gone hi-tech. Cabinet ministers meet weekly in a room fitted with more than a dozen high-end computers, complete with flat screen monitors and broadband connections.
Hip equipment doesn't mean much. When I see our Russian cabinet meetings on TV, they usually sit in a room full of Vaio's, and nobody ever seems to do anything with the laptops, except using them as personal screens for centralized presentations. That doesn't make them any more tech-aware.
It reminds me rather of chained exceptions, available in Java since 1.4. A very nice feature, it's a pity it arrived only this late.
Re:completely underwhelmed by Subversion...
on
Subversion 1.0 Released
·
· Score: 2, Interesting
However, to say that arch is _better_ because it relies on Unix to the extent of being uncompilable on Windows (probably works in cygwin, but...) is bizarre. Arch suffers from the common GNU problem of assuming that a Unix system with a Unixy filesystem is the only environment worth paying attention to, and despite what Richard Stallman might think, that _is_ a problem.
Well, that covers all flavors of Unix, including MacOS X. Windows support is left lagging for now, true, but there sure must be ways to get around its suckage of a filesystem, once the architecture is gotten right.
As other posters said, it's much more simple, and more to the point, to manage changesets rather than snapshots. Expect it to be more simple on Windows, too. Just compare the speed of development of the mentioned two projects. Actually, Tom Lord took part in initial development at SVN, became frustrated and rolled his own. His initial script-based implementation was rewritten in C since then to surpass SVN in core features (while, admittedly, lacking on UI front) -- all this while SVN kept plodding to its first stable release.
Subversion: a cross-platform library for which many tools can be (and have been) made for many environments.
Arch: a Monolithic Unix program. Attempts to port and to add tools are still ongoing.
You got it here. But I have seen many a program, deemed useful, to be recast into program+library layout.
As it seems now, Arch is still in its youth. Yet when it comes of age, expect it to make them who chose Subversion or BitKeeper for their source repositories to reconsider their decisions.
He started bogofilter and put out initial versions. It was picked up by other people since then. However, the initial design decisions were sound, and mostly made it to this day.
Add to that the ability to tweak configuration in batch mode, using off-the-shelf tools such as XSLT processors. Given that transformation stylesheet is correct (and that is easy to achieve for most tasks), you could not break a valid configuration file in spite of all possible variations in layout. Compare that to writing a Perl script to tweak something in the present XFree86 config. I wrote such scripts (for Apache, mainly, but it's the same bag of problems -- and another format to solve them for), and I can attest they tend to be brittle and/or kludgy, because all the wrinkles in the format are so easy to overlook and so tricky to handle. With XML, this has been looked after by the tool developers.
Re:What did they miss about checked exceptions
on
How C# Was Made
·
· Score: 1
The sad truth is, programmers never bother to update, even if they should care about the new exception. The interviewer was right on the money: when a throw specification changes, it's a breaking change, whether it's checked or not. And it's better be checked, lest you get unexpected exceptions popping up in production code. When exceptions are checked, you're aware of the new exception the first time you compile against the upgraded method.
Have you ever designed a moderately complex system? On the scale of individual classes, yes, I be as OOP-minded as the next guy. But dealing with hundreds of classes requires separating functionally different parts of your program to subsystems, with reduced and well-defined coupling between them. This hasn't changed since the days of procedural programming. Except, with careful use of new tricks like exceptions (pun intended), you can define it better.
What did they miss about checked exceptions
on
How C# Was Made
·
· Score: 4, Insightful
I must say he doesn't seem to grok exceptions very well.
Anders Hejlsberg: The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.
Well, if you're a Java programmer worth your salt, you DON'T propagate every exception class the underlying modules might want to throw. You make your code catch exceptions rising from below and either handle them or massage them into the exception set your module exports. This is much better for the upper-level users because they want to deal only with situations raised by, and meaningful for, the APIs at hand, and they don't have to care about what would brew beneath. If you don't want to lose exception stack information, as of J2SE 1.4, you can chain an original exception to your higher-level exception, so that everything would be rolled down nicely in a trace printout.
Actually, this site is run by some ex-staff of the eponymous paper after its collapse. They are no more overtly pro-Communist, and they're hardly pro-government, even if they declare their stance as "pro-Russian". In fact, they're as independent as you can get. Here's what they tell about themselves.
We like to use other technologies when they work, and we use (and/or invent) better ones if the existing things don't work properly. (See CORBA.)
You point an interesting example in that it, too, shows little more than differences in development philosophy. Below I'll represent the respective team's decisions as I understand them.
KDE: "Oh no, CORBA is bad, we don't grok it, the existing free implementations suck, we don't like its exceptions, we don't like inout parameters. Let's sit and hack together our own private cozy remote object layer." To pay them more justice, KDE is predominantly written in C++ and the CORBA C++ binding is truly horrendous.
GNOME: Let a group of talented hackers implement an ORB in plain C. As the result, get a remote object layer sufficient for the project's purposes and a lightweight and efficient, standard-compliant ORB for the rest of the world to use. Heck, you can now seamlessly import remote objects in Python.
X merely marks the text as selected. That's because it avoids unnecessary network transfer in case the application is running remotely. The second reason is that it enables "content-type negotiation", between the copying and pasting programs. One of the consequences is that if you select text and close that program then that data is gone! This is unexpected
data loss, as bad (to Joe Enduser) as your os randomly deleting files on disk.
X is not alone in this choice of a clipboard API. A Win32 application can either hand its clipboard data to the system and forget about it, or signal readiness to render clipboard content on demand in one or more representations (this, as you mention, is the main point of on-demand copying). When an application exits, it's nice of it to leave its leftover clipboard data to the system. I can't tell whether this is possible also for X selection; judging from its "the selection you can copy is what you see selected on the screen" metaphor, it's probably not.
A 21" Barco Reference Calibrator back from 1996 or so, bought on a fire sale from some design studio. This mean mofo takes a sizable part of my desk space. The colors are still perfect, thanks to the built-in optical sensor.
Slashdot Mirror
Apparently CowboyNeal was left speechless by the news, to the point of leaving the "dept." field blank.
While I haven't RTFA yet, I find the premise stated in the posting somewhat far-fetched. If I need binaries tuned finer than those provided by binary .rpm's, I can take their respective .src.rpm's and rebuild them. The RPM build system, in the distributions I know, provides a convenient way to override optimization flags via system- or user-settable macros. As for compilation time, it's not an issue for most packages these days, as many Gentoo users here can testify.
My soundcard is capable of 6 channels 24bit/96kHz and is quite affordable. These days 7.1 24bit/192kHz is no uber-equipment either.
By moving I meant relocating to Moscow, St.Petersburg, Novosibirsk, or other big city that has the software industry going. This is not entirely impossible. Leaving the country is still an option too, as you mention. Anyway, there is always a choice.
The counterparts of many American geeks in Russia couldn't find a well paying job
Yeah, cry me a river. At least in major sities, this is not the case. The definition of "well paying" may vary, but we're talking about Russian standards here. It's more like the employers can't find adequate geeks to man the jobs.
In small shitholes, it can be tougher (what country has it the other way?). But nothing really prevents people from moving anymore.
The bottom line is: these people have deliberately chosen to be scumbags.
I don't know, but an ISP headed by Chief Fast Horse has some positive chime to it.
The Gulf of Mexico. It already has a chemical-triggered dead zone where algae bloom and die, causing oxygen depletion. Might as well produce oil.
How about a summary for those of us who didn't understand a word of that story
Get lost. This is Slashdot.
(Just kidding, don't take it personal)
They made me feel pretty stupid for asking.
Recalling one spectacular $1e8-figure failure somewhere in the Solar System, I think it's sometimes better to ask.
Even the Estonian government has gone hi-tech. Cabinet ministers meet weekly in a room fitted with more than a dozen high-end computers, complete with flat screen monitors and broadband connections.
Hip equipment doesn't mean much. When I see our Russian cabinet meetings on TV, they usually sit in a room full of Vaio's, and nobody ever seems to do anything with the laptops, except using them as personal screens for centralized presentations. That doesn't make them any more tech-aware.
Check this poster's history. It's full of crap like this.
It reminds me rather of chained exceptions, available in Java since 1.4.
A very nice feature, it's a pity it arrived only this late.
Well, that covers all flavors of Unix, including MacOS X. Windows support is left lagging for now, true, but there sure must be ways to get around its suckage of a filesystem, once the architecture is gotten right.
As other posters said, it's much more simple, and more to the point, to manage changesets rather than snapshots. Expect it to be more simple on Windows, too. Just compare the speed of development of the mentioned two projects. Actually, Tom Lord took part in initial development at SVN, became frustrated and rolled his own. His initial script-based implementation was rewritten in C since then to surpass SVN in core features (while, admittedly, lacking on UI front) -- all this while SVN kept plodding to its first stable release.
You got it here. But I have seen many a program, deemed useful, to be recast into program+library layout.
As it seems now, Arch is still in its youth. Yet when it comes of age, expect it to make them who chose Subversion or BitKeeper for their source repositories to reconsider their decisions.
He started bogofilter and put out initial versions. It was picked up by other people since then. However, the initial design decisions were sound, and mostly made it to this day.
Add to that the ability to tweak configuration in batch mode, using off-the-shelf tools such as XSLT processors. Given that transformation stylesheet is correct (and that is easy to achieve for most tasks), you could not break a valid configuration file in spite of all possible variations in layout.
Compare that to writing a Perl script to tweak something in the present XFree86 config. I wrote such scripts (for Apache, mainly, but it's the same bag of problems -- and another format to solve them for), and I can attest they tend to be brittle and/or kludgy, because all the wrinkles in the format are so easy to overlook and so tricky to handle. With XML, this has been looked after by the tool developers.
The sad truth is, programmers never bother to update, even if they should care about the new exception.
The interviewer was right on the money: when a throw specification changes, it's a breaking change, whether it's checked or not. And it's better be checked, lest you get unexpected exceptions popping up in production code. When exceptions are checked, you're aware of the new exception the first time you compile against the upgraded method.
Have you ever designed a moderately complex system?
On the scale of individual classes, yes, I be as OOP-minded as the next guy. But dealing with hundreds of classes requires separating functionally different parts of your program to subsystems, with reduced and well-defined coupling between them. This hasn't changed since the days of procedural programming. Except, with careful use of new tricks like exceptions (pun intended), you can define it better.
Well, if you're a Java programmer worth your salt, you DON'T propagate every exception class the underlying modules might want to throw. You make your code catch exceptions rising from below and either handle them or massage them into the exception set your module exports. This is much better for the upper-level users because they want to deal only with situations raised by, and meaningful for, the APIs at hand, and they don't have to care about what would brew beneath.
If you don't want to lose exception stack information, as of J2SE 1.4, you can chain an original exception to your higher-level exception, so that everything would be rolled down nicely in a trace printout.
Actually, this site is run by some ex-staff of the eponymous paper after its collapse. They are no more overtly pro-Communist, and they're hardly pro-government, even if they declare their stance as "pro-Russian". In fact, they're as independent as you can get.
Here's what they tell about themselves.
We like to use other technologies when they work, and we use (and/or invent) better ones if the existing things don't work properly. (See CORBA.)
You point an interesting example in that it, too, shows little more than differences in development philosophy. Below I'll represent the respective team's decisions as I understand them.
KDE: "Oh no, CORBA is bad, we don't grok it, the existing free implementations suck, we don't like its exceptions, we don't like inout parameters. Let's sit and hack together our own private cozy remote object layer." To pay them more justice, KDE is predominantly written in C++ and the CORBA C++ binding is truly horrendous.
GNOME: Let a group of talented hackers implement an ORB in plain C. As the result, get a remote object layer sufficient for the project's purposes and a lightweight and efficient, standard-compliant ORB for the rest of the world to use. Heck, you can now seamlessly import remote objects in Python.
X is not alone in this choice of a clipboard API. A Win32 application can either hand its clipboard data to the system and forget about it, or signal readiness to render clipboard content on demand in one or more representations (this, as you mention, is the main point of on-demand copying). When an application exits, it's nice of it to leave its leftover clipboard data to the system. I can't tell whether this is possible also for X selection; judging from its "the selection you can copy is what you see selected on the screen" metaphor, it's probably not.
Here and here you can see the image taken on Oct. 4, in a more conventional format.
A 21" Barco Reference Calibrator back from 1996 or so, bought on a fire sale from some design studio. This mean mofo takes a sizable part of my desk space. The colors are still perfect, thanks to the built-in optical sensor.
These are the guys who ported WTL to Windows CE.