Actually, that's not as silly as it sounds. IIRC the Beeb's PSU produces fairly standard 5V and maybe 12V and the machine doesn't draw all that much power. I would have thought it would be quite easy to find a standard PSU of appropriate spec that could be substituted.
While it wasn't C++, I have used multiple inheritence as a mixin mechanism to implement a common protocol (e.g. propogating events) across classes that have ownership relationships but no other inheritance. The non-contrived examples I've seen for multiple inheritance all tend to be this sort of thing. Multiple inheritance isn't completely useless. You would probably find it useful for implementing default behaviours in environments where there are multiple sources of program control coming from a framework that an object has to play nicely with. One example might be a widget library for a GUI toolkit.
You can - at some expense - get fire rated safes that will protect magnetic media against a substantial fire. A small one is a few hundred pounds, although larger ones run into many thousands. You might consider a safe of this type.
I suspect that for every distributed OSS project that succeeds there are many that fail. You see the successful projects and the failed ones tend to slip back into obscurity. You can possibly learn something from the ones that succeed, but it shouldn't be 'OSS projects successfully manage distributed teams all the time.' I think that the majority of such projects actually fail. However, reaching out for advice or examples from the ones that actually work might be helpful. You should find folks on Slashdot who actually are involved with successful OSS projects. Maybe they will have something worthwhile to say.
You can still buy high quality PCs these days - they're called workstations. If you just want a good quality PC then take a look at an entry level workstation like a HP Z230 or a Dell T1700. One of the markets these machines are sold into is desktops running mission critical apps that have to meet SLAs. They tend to be built to higher standards than mainstream PCs.
I did my undergrad degree on a lab not unlike this (actually Sun workstations using NIS/NFS to mount home directories - this was the 1990s). These machines were likely an 1-2 orders of magnitude less powerful than even your smallest desktop - desktops with 32MB of RAM and servers with 128-256MB. There was no resource management aside from disk quotas and the lab worked fine.
Depending on what you mean by high-usage I would have thought even modest desktop systems would be powerful enough for just about anything people get up to in a university lab (unless you mean Z800s with 192GB of RAM and somebody with an application for a machine that big). You could try goosing your smaller desktops by searching for 20-40GB SSDs to use as system disks (this should be plenty for the O/S, installed applications and swap) or upgrading the memory; SSDs like that go for peanuts on ebay.
I see java/database arguments and flamewars pop up from time to time. They usually centre on the performance vs. portability argument. I'll admit to some bias towards the smart-database school. Here's my $0.02 worth on this particular debate.
The fallacy of total database independence
For political reasons Sun would like us to treat Java as a platform. Therefore java is designed to be all things to all people, a layer between you and the operating system. This is at odds with what it actually gets used for. The same is arguably true for.NET, though for slightly different reasons.
Neither of these platforms are widely used for developing shrinkwrap software. I'll argue that both platforms are essentially irrelevant to the shrinkwrap software community outside of those companies that make Java or.NET development tools and infrastructure. Most java (or.NET for that matter) development is done for bespoke applications - where the client is paying for all the development and maintenance work. Most importantly, the client also owns and therefore specifies the hardware on which the application will be deployed.
I believe that the key fallacy of the portability argument lies in these four points:
Point 1: M:M application:database relationship
The database is not your personal persistent object store. Other people have to use the data.
Outside the trivial case, databases and applications live in a M:M relationship. The data will be used by more than one application. Tying your data integrity to the middle tier forces you to to go through the middle tier to update it. You have not escaped platform dependence but just moved it up a layer.
Any database has multiple stakeholders, including business users who want to analyse it. Therefore, application developers are not the only stakeholders in a database. Developers often do not realise this until it is pointed out to them.
Point 2: You still need to regression test
Any other platform (hardware, OS etc.) that you intend to support deployment on needs to be regression tested. Even if the application is write-once-run-anywhere portable, you still have to devise, maintain and find the warm bodies to execute a comprehensive regression test. Java's portability is not good enough to avoid this.
Point 3: Java is mostly used for bespoke development
Remember that Java is mostly used for bespoke development. The practical difference between "write-once-run-anywhere" and "relatively easy to port" is not an overwhelming issue on a bespoke project. There is a significant investment in development, and a set of regression tests has to be carried out.
If you have spent $1,000,000 on an application then the difference between $100,000 to regression test it on your new platform and $150,000 to port and regression test it is not such a big deal. The difference between "zero development effort" and "reasonable development effort" is not so significant in this light.
Point 4: O-R mappers are not a substitute for competent developers
If you're developing a database app without reasonable SQL skills on the team you've got bigger problems than portability. The notion of abstracting away data access into a black box is utopian. Data access performance is actually subject to mechanical constraints of disk performance.NOTHING else in the application stack has to actually move chunks of metal and ferrite (or whatever they make GMR heads from these days) around to work.
For this reason, database independence is just as big a myth as network transparency. Hands up those of us who design EJB components without regard to network round trips. You cannot ignore what the database is doing behind the scenes.
My argument is thus:
An application using POJO's and a reasonably competent data layer gives you flexibilit
Now, this is hazily remembered, but a friend's uncle (really!) works as a developer for NZX. He mentioned this in a conversation we had a few months ago. I think the speed increase was through using analytic features of Oracle 10g along with the more powerful hardware.
They replaced various systems running older versions of Oracle with this cluster. I'll ping my friend and maybe get him to find out what this was referring to and post something.
You could try self-publishing. Look up 'Xerox Docutech' and find someone locally that has one. These are an industrial 600dpi (from memory) laser printer designed for bulk printing - they may have higher resolutions now. You can easily print a run of 50 or 100 on these (which is not economical to do on an offset press due to the startup costs) but get the cover offset printed.
Layout the material at something like 7.5x9" (about the size of a computer manual) rather than A4. The book will be a much more sensible size in a bookshelf and the you need to guillotine it anyway to avoid the edges looking rough.
If you need gray scales in your cartoons, render them as error diffusion dithers in a high resolution (i.e. 600dpi) one-bit bitmap. Halftones tend to look rough when rendered on laser printers. Diffusion dithers get better fidelity at a given resolution and don't look so rough.
You will need to fiddle with the gray scale of the image before converting to a dithered bitmap. The printer will tend to fill in dark areas as solids due to flaring (the toner gets slightly squashed out during fusing). You will need to experiment with this to see to get the image right.
Find a laser-friendly matt art paper of 100-120gsm weight from a wholesale paper merchant. It will look considerably better than ordinary photocopy paper. As I mentioned before, get the cover done on card (250-300gsm) on an offset press. This will be expensive but the plates will be re-useable for later runs if the book is successful.
This won't be cheap but it will be economical for a short run to test the waters. The only fixed startup costs are for the platemaking for the cover. Modern PC's have enough juice to edit large bitmap images and any imaging program will be able to do the tone adjustment and conversion to dithered images. Splash out for a used copy of Pagemaker on Ebay if you need to do the layout work. This will cost less than the plates for a colour cover. Don't try to do it on Word.
More seriously, though, there are plenty of tasks that are complicated enough that they can't be scripted. My guess is that you didn't rely on a script to post your comment to/., and you probably don't rely on one when you compose email, draw pictures, play music, or organize your pr0n collection.
Actually I do use shell scripts to organise my pr0n collection:
for a in `ls`; do
if [ -d $a ] ; then
if [ $a != Thumbnails -a $a != Large ]; then
(cd $a; f=`dhtml`)
echo "<p><a href=$a/pp.html>$a</a>" >>pp.html
fi
fi done
One field where visual languages are widely used is EAI tools such as CrossWorlds and BizTalk. The schema designers essentially amount to a visual language for coding data transformations. The vendors of these products portray them as tools where a team of end-users or (at worst) business analysts can develop a schema using a visual tool and deploy the EAI process without having to do any "programming"
The reality is that processes of non-trivial complexity are too hard to develop visually. On any non-trivial Crossworlds or BizTalk application most complex transformations end up taking the form of: Start -> Run procedure XYZ of {C#/Java/whaterver} code -> Stop The visual schema designers are too hard to develop non-trivial processes in and it's much easier to write it in a "conventional" programming language.
There are two reasons for this:
i. Screen real-estate is limited by physical constraints that other aspects of computing power aren't - specifically, it's limited by the spacial characteristics of the screen and the resolution of he screen and (ultimately) the eye and the brain's ability to impose structure and navigate a complex diagram.
ii. Visual flow diagrams have relatively little ability to meaningly support abstract programming, so software engineering practices such as functional decomposition, abstract data types (let alone inheritance or higher-order functions) - or even code reuse - have not ever been done well in a visual language.
Check out Morphic (http://www.squeak.org/features/graphics.html) to see the best example of a visual language with any attempt at general programming constructs. Even this is severely limited in the practical levels of complexity that can be attained using it.
Until Someone comes up with a visual "metaphor" (for want of something better to call it) for software development that allows programming abstractions as conveniently as textual code does, I can't see visual programming languages emerging out of their niche markets.
Bear in mind that programmer-free MIS development has been something of a holy grail for 20 or 30 years now (much like artificial intelligence). In spite of 20 or 30 years and many millions of dollars thrown at the problem, no-one has managed to get it right yet. IMO, this is a pipe-dream and only gets more so as IT infrastructure gets more complex.
SQL Server is actually a variant of Sybase. The SQL dialect still remains very similar; You might not have too much trouble shifting from SQL Server to Sybase. It's not free, but it does run on Linux.
Nigel
What a golden opportunity ...
on
Code Red III
·
· Score: 1
Well, the obvious way to treat a portscan from a code red infected machine is...
Server Name: foobar.luser.com
IP Address: 66.66.66.66
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
[nobby@nobby]$ cat > unsolicited.email
Dear Sir,
It has come to my attention that your server FOOBAR
has been infected with a variation of the CODE RED
worm. I would like to draw your attention to our
one-time only introductory offer of a complete new
webserver installation on a platform GUARANTEED never
to be infected with the CODE RED worm ever again!
That's right! For the one time payment of a low, low
price of only $2999.95, we can completely rebuild your
web server with a platform GUARANTEED never to be
infected with CODE RED ever again...
This is a never-to-be-repeated once-in-a-lifetime
offer!
Yours Sincerely,
[insert name here]
^D
[nobby@nobby]$ for a in administrator bofh 1337_MCSE_d00d ceo webmaster; do mail -s "Your web server has been infected..." < unsolicited.email ${a}@luser.com; done
It was encrypted sections of the binary. This was a very common method used to obfusticate copy protection mechanisms in software back in the days that people used to do that. I can remember disassembling games on one or two 8-bit architectures for the purposes of er.. making backup copies. There is no reason to write code that does this other than to obscure its intent from casual observation.
I met my significant other at University, in a Computer Science department, no less. Nobby's 2-step guide to finding your perfect partner:
1. Show your feelings to people you fancy. If they don't know you're interested, they won't respond. Be nice to them and don't be too much of a HNG, but make sure they know how you feel.
2: Repeat 1.
Obviously, there are self confidence issues in this. Fear of rejection is the biggest one but a gross oversimplification in the general case. Just because you're a geek doesn't make you unattractive. One of my friends is very geeky, but he wears it with self-confidence. It "works" on him -- He's profoundly comfortable in his space and shows it. He attracted someone enough that she took the effort to seek him out.
Sophia Loren said something along the lines of "Sex appeal is 50% what you've got and 50% what you think you've got." I could go into a long story about some events in my life and a profound shift in my own sexual self-image, but I won't. What I will say is that the before and after effects were dramatic -- I'd say the ratio is more like 80/20. What we project in our mannerisms and body language reflects aspects of our personality and is by far the strongest force for attraction. Many physically attractive people give me a big soft-on through obvious falseness or mannerisms, facial expressions or other cues. Conversely, many physically plain people are very attractive through giving off a "warm vibe." Some of the sexiest people I know are not "lookers" at all.
Low self-esteem often goes along with geekdom because of the social stigmas attached to it. Any of Jon Katz's Hellmouth articles or articles related to them give a fairly realistic account of the formative experiences of geeks in most western school systems. They certainly gel with my experiences of High School. Geeks are also usually portrayed negatively on Television.
At the risk of making many sweeping generalisations that I promised not to make earlier, Much of this low self-esteem is an entirely artificial social construct (IMNSHO) and not really a function of any inherent fucked-upness. While adolescent geeks may often be immature, consider the average level of maturity of a "mainstream" 15-year old.
I could rant on this topic for hours (it's a pet subject, hadn't you noticed). Sometime I'll stop procrastinating and write a decent blurb on this topic.
Slashdot Mirror
I seem to remember something that did that back around 1970. What was it called - Harmony, Consensus or something like that?
Acorn used to supply a circuit diagram and fairly good reference docs for the BBC.
Actually, that's not as silly as it sounds. IIRC the Beeb's PSU produces fairly standard 5V and maybe 12V and the machine doesn't draw all that much power. I would have thought it would be quite easy to find a standard PSU of appropriate spec that could be substituted.
While it wasn't C++, I have used multiple inheritence as a mixin mechanism to implement a common protocol (e.g. propogating events) across classes that have ownership relationships but no other inheritance. The non-contrived examples I've seen for multiple inheritance all tend to be this sort of thing. Multiple inheritance isn't completely useless. You would probably find it useful for implementing default behaviours in environments where there are multiple sources of program control coming from a framework that an object has to play nicely with. One example might be a widget library for a GUI toolkit.
One, in particular, comes to mind.
You can - at some expense - get fire rated safes that will protect magnetic media against a substantial fire. A small one is a few hundred pounds, although larger ones run into many thousands. You might consider a safe of this type.
I suspect that for every distributed OSS project that succeeds there are many that fail. You see the successful projects and the failed ones tend to slip back into obscurity. You can possibly learn something from the ones that succeed, but it shouldn't be 'OSS projects successfully manage distributed teams all the time.' I think that the majority of such projects actually fail. However, reaching out for advice or examples from the ones that actually work might be helpful. You should find folks on Slashdot who actually are involved with successful OSS projects. Maybe they will have something worthwhile to say.
You can still buy high quality PCs these days - they're called workstations. If you just want a good quality PC then take a look at an entry level workstation like a HP Z230 or a Dell T1700. One of the markets these machines are sold into is desktops running mission critical apps that have to meet SLAs. They tend to be built to higher standards than mainstream PCs.
I did my undergrad degree on a lab not unlike this (actually Sun workstations using NIS/NFS to mount home directories - this was the 1990s). These machines were likely an 1-2 orders of magnitude less powerful than even your smallest desktop - desktops with 32MB of RAM and servers with 128-256MB. There was no resource management aside from disk quotas and the lab worked fine.
Depending on what you mean by high-usage I would have thought even modest desktop systems would be powerful enough for just about anything people get up to in a university lab (unless you mean Z800s with 192GB of RAM and somebody with an application for a machine that big). You could try goosing your smaller desktops by searching for 20-40GB SSDs to use as system disks (this should be plenty for the O/S, installed applications and swap) or upgrading the memory; SSDs like that go for peanuts on ebay.
I see java/database arguments and flamewars pop up from time to time. They usually centre on the performance vs. portability argument. I'll admit to some bias towards the smart-database school. Here's my $0.02 worth on this particular debate.
The fallacy of total database independence
For political reasons Sun would like us to treat Java as a platform. Therefore java is designed to be all things to all people, a layer between you and the operating system. This is at odds with what it actually gets used for. The same is arguably true for .NET, though for slightly different reasons.
Neither of these platforms are widely used for developing shrinkwrap software. I'll argue that both platforms are essentially irrelevant to the shrinkwrap software community outside of those companies that make Java or .NET development tools and infrastructure. Most java (or .NET for that matter) development is done for bespoke applications - where the client is paying for all the development and maintenance work. Most importantly, the client also owns and therefore specifies the hardware on which the application will be deployed.
I believe that the key fallacy of the portability argument lies in these four points:
Point 1: M:M application:database relationship
The database is not your personal persistent object store. Other people have to use the data.
Outside the trivial case, databases and applications live in a M:M relationship. The data will be used by more than one application. Tying your data integrity to the middle tier forces you to to go through the middle tier to update it. You have not escaped platform dependence but just moved it up a layer.
Any database has multiple stakeholders, including business users who want to analyse it. Therefore, application developers are not the only stakeholders in a database. Developers often do not realise this until it is pointed out to them.
Point 2: You still need to regression test
Any other platform (hardware, OS etc.) that you intend to support deployment on needs to be regression tested. Even if the application is write-once-run-anywhere portable, you still have to devise, maintain and find the warm bodies to execute a comprehensive regression test. Java's portability is not good enough to avoid this.
Point 3: Java is mostly used for bespoke development
Remember that Java is mostly used for bespoke development. The practical difference between "write-once-run-anywhere" and "relatively easy to port" is not an overwhelming issue on a bespoke project. There is a significant investment in development, and a set of regression tests has to be carried out.
If you have spent $1,000,000 on an application then the difference between $100,000 to regression test it on your new platform and $150,000 to port and regression test it is not such a big deal. The difference between "zero development effort" and "reasonable development effort" is not so significant in this light.
Point 4: O-R mappers are not a substitute for competent developers
If you're developing a database app without reasonable SQL skills on the team you've got bigger problems than portability. The notion of abstracting away data access into a black box is utopian. Data access performance is actually subject to mechanical constraints of disk performance. NOTHING else in the application stack has to actually move chunks of metal and ferrite (or whatever they make GMR heads from these days) around to work.
For this reason, database independence is just as big a myth as network transparency. Hands up those of us who design EJB components without regard to network round trips. You cannot ignore what the database is doing behind the scenes.
My argument is thus:
An application using POJO's and a reasonably competent data layer gives you flexibilit
Now, this is hazily remembered, but a friend's uncle (really!) works as a developer for NZX. He mentioned this in a conversation we had a few months ago. I think the speed increase was through using analytic features of Oracle 10g along with the more powerful hardware.
They replaced various systems running older versions of Oracle with this cluster. I'll ping my friend and maybe get him to find out what this was referring to and post something.
Is it just me or might this be (at least in part) a colossal bribe to hardware manufacturers to get them to buy into MS's lock-in strategy?
[Adjusts tinfoil hat]
You could try self-publishing. Look up 'Xerox Docutech' and find someone locally that has one. These are an industrial 600dpi (from memory) laser printer designed for bulk printing - they may have higher resolutions now. You can easily print a run of 50 or 100 on these (which is not economical to do on an offset press due to the startup costs) but get the cover offset printed.
Layout the material at something like 7.5x9" (about the size of a computer manual) rather than A4. The book will be a much more sensible size in a bookshelf and the you need to guillotine it anyway to avoid the edges looking rough.
If you need gray scales in your cartoons, render them as error diffusion dithers in a high resolution (i.e. 600dpi) one-bit bitmap. Halftones tend to look rough when rendered on laser printers. Diffusion dithers get better fidelity at a given resolution and don't look so rough.
You will need to fiddle with the gray scale of the image before converting to a dithered bitmap. The printer will tend to fill in dark areas as solids due to flaring (the toner gets slightly squashed out during fusing). You will need to experiment with this to see to get the image right.
Find a laser-friendly matt art paper of 100-120gsm weight from a wholesale paper merchant. It will look considerably better than ordinary photocopy paper. As I mentioned before, get the cover done on card (250-300gsm) on an offset press. This will be expensive but the plates will be re-useable for later runs if the book is successful.
This won't be cheap but it will be economical for a short run to test the waters. The only fixed startup costs are for the platemaking for the cover. Modern PC's have enough juice to edit large bitmap images and any imaging program will be able to do the tone adjustment and conversion to dithered images. Splash out for a used copy of Pagemaker on Ebay if you need to do the layout work. This will cost less than the plates for a colour cover. Don't try to do it on Word.
Actually I do use shell scripts to organise my pr0n collection:
The reality is that processes of non-trivial complexity are too hard to develop visually. On any non-trivial Crossworlds or BizTalk application most complex transformations end up taking the form of:
Start -> Run procedure XYZ of {C#/Java/whaterver} code -> Stop
The visual schema designers are too hard to develop non-trivial processes in and it's much easier to write it in a "conventional" programming language.
There are two reasons for this:
i. Screen real-estate is limited by physical constraints that other aspects of computing power aren't - specifically, it's limited by the spacial characteristics of the screen and the resolution of he screen and (ultimately) the eye and the brain's ability to impose structure and navigate a complex diagram.
ii. Visual flow diagrams have relatively little ability to meaningly support abstract programming, so software engineering practices such as functional decomposition, abstract data types (let alone inheritance or higher-order functions) - or even code reuse - have not ever been done well in a visual language.
Check out Morphic (http://www.squeak.org/features/graphics.html) to see the best example of a visual language with any attempt at general programming constructs. Even this is severely limited in the practical levels of complexity that can be attained using it.
Until Someone comes up with a visual "metaphor" (for want of something better to call it) for software development that allows programming abstractions as conveniently as textual code does, I can't see visual programming languages emerging out of their niche markets.
Bear in mind that programmer-free MIS development has been something of a holy grail for 20 or 30 years now (much like artificial intelligence). In spite of 20 or 30 years and many millions of dollars thrown at the problem, no-one has managed to get it right yet. IMO, this is a pipe-dream and only gets more so as IT infrastructure gets more complex.
SQL Server is actually a variant of Sybase. The SQL dialect still remains very similar; You might not have too much trouble shifting from SQL Server to Sybase. It's not free, but it does run on Linux.
Nigel
Well, the obvious way to treat a portscan from a code red infected machine is ...
/var/log/messages
...
..." < unsolicited.email ${a}@luser.com; done
[nobby@nobby]$ grep "Packet"
Jul 15 20:53:32 pat kernel: Packet log: input DENY ppp0 PROTO=6 xx.xx.xx.xx: 80 203.66.66.66.66:1040 L=...
[snip]
[nobby@nobby]$ whois 66.66.66.66
[snip]
Server Name: foobar.luser.com
IP Address: 66.66.66.66
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
[nobby@nobby]$ cat > unsolicited.email
Dear Sir,
It has come to my attention that your server FOOBAR
has been infected with a variation of the CODE RED
worm. I would like to draw your attention to our
one-time only introductory offer of a complete new
webserver installation on a platform GUARANTEED never
to be infected with the CODE RED worm ever again!
That's right! For the one time payment of a low, low
price of only $2999.95, we can completely rebuild your
web server with a platform GUARANTEED never to be
infected with CODE RED ever again
This is a never-to-be-repeated once-in-a-lifetime
offer!
Yours Sincerely,
[insert name here]
^D
[nobby@nobby]$ for a in administrator bofh 1337_MCSE_d00d ceo webmaster; do mail -s "Your web server has been infected
It was encrypted sections of the binary. This was a very common method used to obfusticate copy protection mechanisms in software back in the days that people used to do that. I can remember disassembling games on one or two 8-bit architectures for the purposes of er .. making backup copies. There is no reason to write code that does this other than to obscure its intent from casual observation.
1. Show your feelings to people you fancy. If they don't know you're interested, they won't respond. Be nice to them and don't be too much of a HNG, but make sure they know how you feel.
2: Repeat 1.
Obviously, there are self confidence issues in this. Fear of rejection is the biggest one but a gross oversimplification in the general case. Just because you're a geek doesn't make you unattractive. One of my friends is very geeky, but he wears it with self-confidence. It "works" on him -- He's profoundly comfortable in his space and shows it. He attracted someone enough that she took the effort to seek him out.
Sophia Loren said something along the lines of "Sex appeal is 50% what you've got and 50% what you think you've got." I could go into a long story about some events in my life and a profound shift in my own sexual self-image, but I won't. What I will say is that the before and after effects were dramatic -- I'd say the ratio is more like 80/20. What we project in our mannerisms and body language reflects aspects of our personality and is by far the strongest force for attraction. Many physically attractive people give me a big soft-on through obvious falseness or mannerisms, facial expressions or other cues. Conversely, many physically plain people are very attractive through giving off a "warm vibe." Some of the sexiest people I know are not "lookers" at all.
Low self-esteem often goes along with geekdom because of the social stigmas attached to it. Any of Jon Katz's Hellmouth articles or articles related to them give a fairly realistic account of the formative experiences of geeks in most western school systems. They certainly gel with my experiences of High School. Geeks are also usually portrayed negatively on Television.
At the risk of making many sweeping generalisations that I promised not to make earlier, Much of this low self-esteem is an entirely artificial social construct (IMNSHO) and not really a function of any inherent fucked-upness. While adolescent geeks may often be immature, consider the average level of maturity of a "mainstream" 15-year old.
I could rant on this topic for hours (it's a pet subject, hadn't you noticed). Sometime I'll stop procrastinating and write a decent blurb on this topic.