At my current company we have a huge number of cold callers, mostly of the automated variety. There's always a pause as the auto-dialer software waits for a human voice rather than a fax, which is when you should randomly press buttons on your touchtone phone. This either fools the software into thinking it's called a fax line, and removing you from its call list, or transfers you to a human. In the latter case, it's now fun time. My two favourite games (shamelessly nicked from someone else) are:
1. Answer every question or prompt with one word, usually "yes", but extra points for something else
2. Pretend you are a law enforcement officer at a crime scene, and question the telemarketer as to their relationship with "the deceased", ascertain their location and then pretend a unit is on its way to question them
Chips aren't exactly designed to "run Linux" or any other OS.
To be pedantic, most processors are designed to run an OS, in that they have features that are specifically required for the way operating systems are implemented. Support for things like privilege levels for example.
Until the fix the TX number issue ( the infamous rollover ) then they are pretty much out of the running in DB's that have VERY high insert levels since the vacuum process cannot hope to keep up with tables that have 100's of millions of rows.
Infamous to whom? A vacuum updates the frozen TID, which is a trivial operation and allows a subsequent TID to safely wrap around. And I'm struggling to think of any common use cases where the volume of inserts is so high that they can't afford a vacuum every two billion transactions - even high-frequency trading doesn't operate at those levels, and if it did I suspect TID wraparounds would not be your most pressing concern.
Play ethnicky jazz
To parade your snazz
That you download from the Pirate Bay
Braggin' that you know
How to skip out on a charge
Where the Swedish law's got no say
Nah, you're not from the UK - no one here refers to themselves as British.
Re:CDE and LessTif are both LGPL, but v2 vs. v3?
on
CDE Open Sourced
·
· Score: 1
I actually paid for CND back in the day to get a Motif license...
I bought a CD-ROM of Motif 2.0 from RedHat way back in 1996 - I think it was the only thing they sold that didn't come with source code. When I recently moved house I found the CD-ROM, along with another disc containing a compilation of XView stuff that Ian Darwin used to sell.
Sun seemed to think no one cared about color depth until '97 or so. They did sell a few systems with 24-bit color, but they were expensive as hell.
Yup. most Sun systems like my SparcStation 5 shipped with 8 bit framebuffers that caused the screen to flash horribly if you switched between the windows of applications that were using different palettes. I eventually upgraded to a 24 bit LX framebuffer, which set me back an eye watering £575 in 1998.
I guess you've looked at the XView libraries on a 64 bit PC. XView was created by Sun as a way of easing the transition from SunView (their proprietary windowing system) to the X Window System, and the code was later open sourced. 64 bit versions of the libraries wont run on amd64 / x86_64, despite being included in places like the Debian repositories. This is due to an assumption in the XView code about the size of data types - an assumption that doesn't hold for the 64 bit Intel world (details here). You may be able to get a 32 bit copy of the libraries running in compatability on a 64 bit version of Linux.
I seem to recall that DCE was open sourced a few years back. Not sure how relevant it would be today, since there are plenty of excellent open source alternatives out there now.
MicroSoft were even involved in the design of Motif and CDE, which took some of its look and feel from Windows 3.1, although I don't think MS contributed to the actual development. I'm pretty sure the Motif programming manuals from O'Reilly even mentioned MicroSoft in the introductory pages.
I do still use NEdit though. Fantastic regex support.
I use NEdit pretty much every working day - it was even my main programming editor of choice for many years.
Re:Submitter/Documentation Lead
on
CDE Open Sourced
·
· Score: 1
Hi Chris,
Thanks for the information. Do you know if The Open Group continued to work on the Motif code after it was partially open sourced as OpenMotif? In other words, are their likely to be changes in The Open Group code that aren't in the 2.3.3 version of OpenMotif that ICS maintain? I assume that The Open Group provided a reference implementation of Motif and CDE to companies like Sun and HP, and that these companies then made their own modifications as they ported it to operating systems like Solaris and HP-UX. Presumably theses changes would have been fed back and assigned to The Open Group, so only minor differences are likely to exist between the current reference implementation and those that were distributed in binary form by the Unix vendors themselves.
Re:CDE and LessTif are both LGPL, but v2 vs. v3?
on
CDE Open Sourced
·
· Score: 5, Informative
LessTif is the (buggy, unmaintained, incomplete) equivalent of Motif. CDE was a dekstop environment that built on top of Motif, providing a kind of task bar and various applications. The only app that Motif provided was a window manager. KDE started as an attempt to provided something similar to CDE, but under an open source license and built on top of the C++ based Qt widget set. Just to confuse things, Qt was open source, but could not be independently distributed with modifications. This licensing quirk, and a preference for C amongst some developers, prompted the creation of the GNOME project to create an alternative desktop environment built on top of the GTK+ widget set. GTK+ had started life as a toolkit for the GIMP image manipulation program - which to take things full circle, was initially written with the Motif toolkit.
SunView was so much more than CDE. SunView was a complete windowing system and widget set, whereas CDE was just a desktop environment built on the Motif widget set for the X-Window system.
You rotter - I loved Open Look, although my memories may be rosy tinted thanks to it being the first GUI I created apps for. I even have my XView programming and reference manuals somewhere - the API was quite nice, paritcularly when you compare it to the horrors of Motif (the widget library that underpins CDE).
In several iterations, disentangle and break the code into smaller and more understandable chunks.
After breaking the code into smaller chunks clean them up (code conventions, algorithms,...) and reorganize as needed.
Depending on the language and the quality of the codebase, this may not be possible. For example, I've worked on a project with 1,000,000+ LOC that defied all attempts to refactor it. This was in C++, which offers a number of features that can help reduce the coupling between code, but in practice the lack of encapsulation meant any refactoring attempt failed. The only answer was a ground up rewrite with a better up front design and thorough code reviews.
Adafruit are great. They produced an enhanced clone of the legendary Roland TB-303 bass synth and sequencer, then open sourced the circuit diagrams. Unlike the dozens of prevous 303 clones, they actually cloned the sequencer which was as essential to the appeal of the machine as the synth section.
The guy sat next to me at work is using Eclipse and Spring Tool Suite (which is based on Eclipse) running on Windows. They look completely native to me, as you'd expect since they use SWT which renders the UI as native widgets. On my Linux machine Eclipse also looks native, since it uses the same GTK+ widgets to render the UI as the rest of the apps I typically use.
You must be the product of a modern "computer science" program. You got some vocational training in Java and were sent out into the world. It's not your fault, you just don't know any better.
Nope. Started my career doing C, Perl and the odd bit of Sparc assembly having learned to program on an Atari ST in the late 1980s. Added C++ to the mix and then Java. Gradually the Java supplanted all the others, since the tools and library support are excellent.
I had an interesting discussion with an American friend over the weekend. We realised that the US has started producing a number of decent lagers in recent years, mostly from relatively small breweries that are able to compete on the basis of quality against the foul pish from companies like Anheuser-Busch. In the same timescale, lager has declined in the UK to the point where it's as bad as the worst of the big name brands from the US. The recent influx of many Poles and Czechs has resulted in the availablility of decent lagers from Eastern Europe though.
Bourbon always tastes so sweet, like candy booze or something.
Each to their own. I love Jack Daniels (and Makers Mark when I'm feeling flush) but can't stand Irish or Scottish Whisk(e)y. It has the added bonus of not giving me blackouts like vodka used to (there again, it might have helped if I hadn't downed a whole bottle of Finlandia in a single evening).
Windows ran fine on a 64 bit architecture in 1996. Perhaps earlier, but that's when I saw it running on a DEC Alpha server. At the time Linux was extremely tricky to port thanks to its origins as a PC operating system, and OpenBSD hadn't yet made a formal release.
Interesting. I read the Smalltalk 80 book a long time ago, but I seem to recall that the state of an object was "public" in the C++ or Java sense of the term. Never really got to use Smalltalk in anger so my recollections may be wrong - I was only really studying it to see how it had influenced Objective-C and the NeXT development framework (which in turn had a major influence on Java).
No no no no NO. Goddamnit NO. Fucking Java. Motherfucking Javascript. They've ruined a generation of programmers. Subclassing is the LAST thing you should be doing.
Can't speak for the JavaScript folks, but in the Java world the best practice is to favour composition over inheritance. So subclassing a button just to change the colour would not be considered good form. The problem with people using inheritance in inappropriate places is down to what I call the "new toy" syndrome. Programmers new to OOP feel they must use it, and to be fair many books tend to place too much empahsise on it (I'm looking at you Mr Stroustrup).
Slashdot Mirror
At my current company we have a huge number of cold callers, mostly of the automated variety. There's always a pause as the auto-dialer software waits for a human voice rather than a fax, which is when you should randomly press buttons on your touchtone phone. This either fools the software into thinking it's called a fax line, and removing you from its call list, or transfers you to a human. In the latter case, it's now fun time. My two favourite games (shamelessly nicked from someone else) are:
1. Answer every question or prompt with one word, usually "yes", but extra points for something else
2. Pretend you are a law enforcement officer at a crime scene, and question the telemarketer as to their relationship with "the deceased", ascertain their location and then pretend a unit is on its way to question them
Chips aren't exactly designed to "run Linux" or any other OS.
To be pedantic, most processors are designed to run an OS, in that they have features that are specifically required for the way operating systems are implemented. Support for things like privilege levels for example.
Until the fix the TX number issue ( the infamous rollover ) then they are pretty much out of the running in DB's that have VERY high insert levels since the vacuum process cannot hope to keep up with tables that have 100's of millions of rows.
Infamous to whom? A vacuum updates the frozen TID, which is a trivial operation and allows a subsequent TID to safely wrap around. And I'm struggling to think of any common use cases where the volume of inserts is so high that they can't afford a vacuum every two billion transactions - even high-frequency trading doesn't operate at those levels, and if it did I suspect TID wraparounds would not be your most pressing concern.
Play ethnicky jazz
To parade your snazz
That you download from the Pirate Bay
Braggin' that you know
How to skip out on a charge
Where the Swedish law's got no say
Nah, you're not from the UK - no one here refers to themselves as British.
I actually paid for CND back in the day to get a Motif license...
I bought a CD-ROM of Motif 2.0 from RedHat way back in 1996 - I think it was the only thing they sold that didn't come with source code. When I recently moved house I found the CD-ROM, along with another disc containing a compilation of XView stuff that Ian Darwin used to sell.
Sun seemed to think no one cared about color depth until '97 or so. They did sell a few systems with 24-bit color, but they were expensive as hell.
Yup. most Sun systems like my SparcStation 5 shipped with 8 bit framebuffers that caused the screen to flash horribly if you switched between the windows of applications that were using different palettes. I eventually upgraded to a 24 bit LX framebuffer, which set me back an eye watering £575 in 1998.
I guess you've looked at the XView libraries on a 64 bit PC. XView was created by Sun as a way of easing the transition from SunView (their proprietary windowing system) to the X Window System, and the code was later open sourced. 64 bit versions of the libraries wont run on amd64 / x86_64, despite being included in places like the Debian repositories. This is due to an assumption in the XView code about the size of data types - an assumption that doesn't hold for the 64 bit Intel world (details here). You may be able to get a 32 bit copy of the libraries running in compatability on a 64 bit version of Linux.
I seem to recall that DCE was open sourced a few years back. Not sure how relevant it would be today, since there are plenty of excellent open source alternatives out there now.
It (and Motif) was based on Windows 3.1.
MicroSoft were even involved in the design of Motif and CDE, which took some of its look and feel from Windows 3.1, although I don't think MS contributed to the actual development. I'm pretty sure the Motif programming manuals from O'Reilly even mentioned MicroSoft in the introductory pages.
I do still use NEdit though. Fantastic regex support.
I use NEdit pretty much every working day - it was even my main programming editor of choice for many years.
Hi Chris, Thanks for the information. Do you know if The Open Group continued to work on the Motif code after it was partially open sourced as OpenMotif? In other words, are their likely to be changes in The Open Group code that aren't in the 2.3.3 version of OpenMotif that ICS maintain? I assume that The Open Group provided a reference implementation of Motif and CDE to companies like Sun and HP, and that these companies then made their own modifications as they ported it to operating systems like Solaris and HP-UX. Presumably theses changes would have been fed back and assigned to The Open Group, so only minor differences are likely to exist between the current reference implementation and those that were distributed in binary form by the Unix vendors themselves.
LessTif is the (buggy, unmaintained, incomplete) equivalent of Motif. CDE was a dekstop environment that built on top of Motif, providing a kind of task bar and various applications. The only app that Motif provided was a window manager. KDE started as an attempt to provided something similar to CDE, but under an open source license and built on top of the C++ based Qt widget set. Just to confuse things, Qt was open source, but could not be independently distributed with modifications. This licensing quirk, and a preference for C amongst some developers, prompted the creation of the GNOME project to create an alternative desktop environment built on top of the GTK+ widget set. GTK+ had started life as a toolkit for the GIMP image manipulation program - which to take things full circle, was initially written with the Motif toolkit.
SunView was so much more than CDE. SunView was a complete windowing system and widget set, whereas CDE was just a desktop environment built on the Motif widget set for the X-Window system.
You rotter - I loved Open Look, although my memories may be rosy tinted thanks to it being the first GUI I created apps for. I even have my XView programming and reference manuals somewhere - the API was quite nice, paritcularly when you compare it to the horrors of Motif (the widget library that underpins CDE).
In several iterations, disentangle and break the code into smaller and more understandable chunks.
After breaking the code into smaller chunks clean them up (code conventions, algorithms, ...) and reorganize as needed.
Depending on the language and the quality of the codebase, this may not be possible. For example, I've worked on a project with 1,000,000+ LOC that defied all attempts to refactor it. This was in C++, which offers a number of features that can help reduce the coupling between code, but in practice the lack of encapsulation meant any refactoring attempt failed. The only answer was a ground up rewrite with a better up front design and thorough code reviews.
Adafruit are great. They produced an enhanced clone of the legendary Roland TB-303 bass synth and sequencer, then open sourced the circuit diagrams. Unlike the dozens of prevous 303 clones, they actually cloned the sequencer which was as essential to the appeal of the machine as the synth section.
The guy sat next to me at work is using Eclipse and Spring Tool Suite (which is based on Eclipse) running on Windows. They look completely native to me, as you'd expect since they use SWT which renders the UI as native widgets. On my Linux machine Eclipse also looks native, since it uses the same GTK+ widgets to render the UI as the rest of the apps I typically use.
You must be the product of a modern "computer science" program. You got some vocational training in Java and were sent out into the world. It's not your fault, you just don't know any better.
Nope. Started my career doing C, Perl and the odd bit of Sparc assembly having learned to program on an Atari ST in the late 1980s. Added C++ to the mix and then Java. Gradually the Java supplanted all the others, since the tools and library support are excellent.
Most of the games on Steam will be DirectX, not OpenGL.
Why will they be? Most of them appear to be OpenGL at the moment.
I don't find Eclipse, NetBeans, SoapUI, Maple and Vuze to be jokes. In fact I use them every day and find them all to be "awesome".
I had an interesting discussion with an American friend over the weekend. We realised that the US has started producing a number of decent lagers in recent years, mostly from relatively small breweries that are able to compete on the basis of quality against the foul pish from companies like Anheuser-Busch. In the same timescale, lager has declined in the UK to the point where it's as bad as the worst of the big name brands from the US. The recent influx of many Poles and Czechs has resulted in the availablility of decent lagers from Eastern Europe though.
Bourbon always tastes so sweet, like candy booze or something.
Each to their own. I love Jack Daniels (and Makers Mark when I'm feeling flush) but can't stand Irish or Scottish Whisk(e)y. It has the added bonus of not giving me blackouts like vodka used to (there again, it might have helped if I hadn't downed a whole bottle of Finlandia in a single evening).
Windows ran fine on a 64 bit architecture in 1996. Perhaps earlier, but that's when I saw it running on a DEC Alpha server. At the time Linux was extremely tricky to port thanks to its origins as a PC operating system, and OpenBSD hadn't yet made a formal release.
Interesting. I read the Smalltalk 80 book a long time ago, but I seem to recall that the state of an object was "public" in the C++ or Java sense of the term. Never really got to use Smalltalk in anger so my recollections may be wrong - I was only really studying it to see how it had influenced Objective-C and the NeXT development framework (which in turn had a major influence on Java).
No no no no NO. Goddamnit NO. Fucking Java. Motherfucking Javascript. They've ruined a generation of programmers. Subclassing is the LAST thing you should be doing.
Can't speak for the JavaScript folks, but in the Java world the best practice is to favour composition over inheritance. So subclassing a button just to change the colour would not be considered good form. The problem with people using inheritance in inappropriate places is down to what I call the "new toy" syndrome. Programmers new to OOP feel they must use it, and to be fair many books tend to place too much empahsise on it (I'm looking at you Mr Stroustrup).