The availability of cheap telescopes does not mean the end of amateur astronomy, it means the end of amateur telescope-building.
I don't agree. The cost of a high quality telescope is still higher than a home-built telescope of the same quality. If you build a scope yourself, it will cost you a lot of time, but most materials are available at reasonable prices. Plus, building your own telescope gives you total control over the quality and design. With some effort, you will be able to build a telescope which outperforms most commercial telescopes.
You can build a telescope mostly from parts you find at a dumpster: some pieces of wood for the base, a cardboard tube, a piece of glass... Take a look at the
San Francisco Sidewalk Astronomers' website, for example.
People have made high-quality optical paraboloidal mirrors from scrap glass, glass candle holders, trepanned discs cut from CRT-tubes, etcetera. I have ground and polished a 7" glass disc into a shape which surface deviates no more than 40 nanometer from an ideal paraboloid. All this takes is a lot of time and patience, and some basic materials. Remember: the first telescopes were built 300 years ago.
The Amateur Telescope Making community is very much alive, try a
google query with these words.
If you're interested in building a telescope, optionally including grinding and polishing your own optics, join the Amateur Telescope Makers mailing list.
"Also out in public beta is iTools, an Apache Port, that looks to have all the goodies like sendmail, DNS, and SSL"
Not quite. Apache, sendmail, dns, OpenSSH; it's already there in the OS X public beta standard installation. iTools is merely a configuration tool for the aforementioned software.
E.C. Robocup winners ran MS-DOS, most other teams
on
Linux Powered Robots
·
· Score: 1
As a software developer for the Dutch Robocup team, I participated in the European Robocup Championship. The winners of last year's Robocup World Cup were the Iranian team, who were invited to join the european championship, which they also won.
Their low-budget hardware design (mostly plastics and wood) was very ingenious: because of the way the wheels turned, the robot was able to rotate around a point some 30 centimeters in front of the robot, where the ball would be. This made it possible to make fast turns without losing the ball.
The vision system used ordinary VHS videocameras, in which they actually put a tape to be able to analyze the game later on. The brains of these bots were motherboards of old '386 desktop machines, running MS-DOS and the soccer software off of a single high-density floppy drive! No team scored a goal against the Iranian team.
The robot I've worked on for the dutch team ran a rather bloated RedHat 6.2 distro on an on-board pentium (don't remember the exact specs). We had a wavelan wireless ethernet interface to communicate with the robot, and to view the diagnostics interface when the robot was running. The software is written in C++. The software uses different layered behaviours, not unlike Rodney Brooks' subsumption architecture. When the conditions for a certain behaviour are met, the behaviour takes control of the actuators. For example, there is an 'emergencybrake' behaviour that sets the speed of the wheels to 0 when the robot suddenly sees an object (other than the ball) in front of it. Other behaviours include driving around looking for the ball and scoring a goal. The software had some problems, mainly because before the tournament, we haven't been able to test the robot in an actual soccer game, but these were mostly fine-tuning problems in the behaviours. The overall architecture worked very well.
> Apple stopped selling Mac OS X Server a week or so ago. It's officially end-of-lifed.
No it's not! Check your facts. It's just temporarily unavailable because quality assurance tests of OSXs running on the new G4s aren't complete yet. The fact that it's not on apple's website doesn't mean you can't order it.
Why do people panic so much without reason? The OS X (server) developers' and administrators' lists are flooded with "aaargh no more os x server" messages. Just wait a few weeks and it'll be there again.
Apple is commited to the Mac admins and their servers. In fact, they're busy with the next version of the fileserver (sort of AppleShare IP running on OS X Server), as a call for selected test sites was made by Apple on the OS X Server admin list. The transition from OS X Server to OS X plus server tools will be fairly smooth, I bet.
They're off by default. In fact, in the installer assistant, there's an option to (dis)allow network access. In the Preferences application, all services can be turned on and off with radio buttons. Any clueless user will have trouble securing their box regardless of the OS. OS X will proably be as vulnerable as most BSDs: It's probably more vulnerable than the old MacOS (because it's a unix), but that's nothing compared to black orified, Outlook using, ActiveX-enabled macro-virus ridden windoze boxes.
The problem with Aqua, for that matter, isn't its appearance, it's its lack of remotability.
If I type "console" at the login window, that's just what I get: a text-only session at the console. Also, by editing the init scripts, you can prevent the Window Manager from starting.
Moreover, ssh runs pretty fine, so remote administration is not really a problem. Besides, Apple's current server software (Netboot server and Macintosh Manager server on OS X Server and Appleshare IP on Mac OS 9) come with GUI remote admin tools. Also, the afpserver (afp = apple filing protocol) on OS X Server is configurable through a web/java based interface. I've used this for over a year on four Mac servers (two OS X Servers, two MacOS 9) and it works fine.
Anyway, my rant on the issue is that sites like MacInsider are touting the fact that the Mach kernel "Has been forged in the fire of open source peer review, etc.", but then they're ripping it out of the open source community and making it proprietary.
The kernel is not proprietary. In fact, the complete, functional core OS, called Darwin, is open source:
Mac-based servers will probably be running OSX Server
Eventually, there won't be an OS X Server. There'll just be an OS X with extra server apps (Netboot server and File server, most importantly).
It's worth noting that although OS X will be a consumer OS, familiar unix services like telnet, sendmail (or postfix, of course), ftp and nfs are installed, and ssh compiles out of the box.
If it turns out apps can be ported from OSX to *nix rather easily, then my bet is on M$ not writing any software for OSX.
I'm not worried about developers writing for *nix and not for OS X.
M$ already has IE 5 shipping with the latest developer preview of OS X, and they will release Office: from what I heard, they're not just porting it from the current MacOS port, they're redoing it in Cocoa, the NeXTStep based (and most kick-ass of all) OS X API.
Other popular software will also be available for OS X, as http://www.apple.com/macosx/apps.html shows. Adobe, Microsoft, ID, Quark and others are listed on that page. Because publishing too much OS X info, particularly screenshots, is not yet possible because of non-disclosure agreements, the software companies will wait until the release of the public beta of OS X in september before they start releasing their OS X based beta's. However, pages like Version Tracker (with a MacOS background) and Softrak (with a NeXT background) already list a fair amount of OS X software, ready to download.
My bet is that there will be a large amount of software for OS X, and there are (at least) four reasons why:
As noted in earlier, OS X will have a large userbase: eventually, practically all Mac owners will have a Mac that runs OS X. The Mac userbase is small compared to the windoze victims, but it's larger than the current *n[iu]x community. And it'll grow because people who want a reasonably priced unix-like system with a good GUI will get an OS X box.
Apple has done a great job by implementing the Carbon API: the Carbon libraries contain almost all old Mac OS toolbox calls, so most current Mac OS applications will recompile under OS X without a great deal of trouble. And carbon apps will benefit from the new memory manager, scheduler, and user interface. See http://www.xappeal.org/carbon/index.shtml for a list of software that is or will be available in carbonized form.
To ease migration to the new OS for old Mac users, Apple created a classic compatibility mode: basicly an application that emulates a Mac running OS 9. It runs all old and non-carbon applications, at roughly 80-90% of the speed it would have if run natively. These apps have the old OS's interface and will crash as often as they did on the old OS, but they won't take the rest of the system down with it.
Apple is putting a lot of work in making OS X usable for non-techy consumers: the average granny should feel happy using an OS X Mac. Everything configurable will have to be configurable by GUI-tools, in fact, the Terminal application won't be installed by default. I doubt it's possible to install and configure a usable other *n[iu]x system without ever editing a config file directly. Developers of consumer products like word processors, mail applications, webbrowsers, audio- and video editing software will like the stability and consumer-orientedness of OS X.
For some excellent technical info on the upcoming OS X, take a look at the reviews Ars Technica did here.
gerti
-- "To invent, you need a good imagination and a pile of junk" - Thomas Edison
Each program is actually a directory that can contain configurations, multiple binaries, different language information, fonts, images, icons, etc. A.app file can be moved around like a file and take all of the required information with it. A novice user need never look under the hood within the BSD layer and find out about all those files.
Actually, configuration files for applications are stored in the ~/Library/Preferences directory. These preferences files are/should be in the PropertyList format: XML files with the 'plist' doctype, using the PropertyList DTD.
Some applications store other stuff in the ~/Library directory. Since some/most applications are stored at locations where mere mortals have no write access (/Local/Applications,/System/Applications and/Network/Applications), the users' config files can't be stored in the.app bundle.
NetInfo typically stores stuff like users/groups, network configuration, printers, services, etcetera. Stuff you would ordinarily assume to be in the/etc directory. The lookupd and netinfod processes serve information from the NetInfo databases to anyone who needs it. When NetInfo doesn't work for some reason, the system can fall back to information in/etc. The NetInfo database itsself is stored in/etc/netinfo/domain.nidb/
The beauty of NetInfo is that it's a distributed database: Machines on a network can connect to a NetInfo server to synchronise and share their configurations.
At the lab I'm working as a system administrator, we're jumping with joy as we see the number of companies that suffer from this virus grow. We're using iMacs, OS X server Macs, and suns running Solaris boxes, and everything is perfectly allright here:-))
> These things have been in common use since the 70's when they ran the first Macs.
The first Mac was released in April 1984. In the late 70's ('79 if I'm correct), the Apple ][ (two) and Apple ][+ were very popular machines, the first home computers to have colour graphics. These machines used the 6502 processor.
Later Apples, the Apple//e and the Apple//c, used a 65C02 cpu. Lots of people put a z80 card in one of the Apple ]['s expansion slots, so you could run cp/m as well (the Apple ][ user could choose DOS 3.3, ProDOS, USCD Pascal and CP/M as an OS).
The first Macs used the Motorola 68000, later Macs had 68020, 68030 or 68040 processors. Unfortunately, in lots of late-68K Macs, Apple put 68LC040s, a 68040 without a copro. The problem with early models of the 68LC040 is that copro emulation wouldn't work due to a bug in the cpu that would destroy the stack pointer. a Bad Thing(tm) indeed.
Now if you'll excuse me, I suffer from acute nostalgia. I'm off to do some vintage computing on one of my Apple ]['s.
Slashdot Mirror
You can build a telescope mostly from parts you find at a dumpster: some pieces of wood for the base, a cardboard tube, a piece of glass... Take a look at the San Francisco Sidewalk Astronomers' website, for example.
People have made high-quality optical paraboloidal mirrors from scrap glass, glass candle holders, trepanned discs cut from CRT-tubes, etcetera. I have ground and polished a 7" glass disc into a shape which surface deviates no more than 40 nanometer from an ideal paraboloid. All this takes is a lot of time and patience, and some basic materials. Remember: the first telescopes were built 300 years ago.
The Amateur Telescope Making community is very much alive, try a google query with these words.
If you're interested in building a telescope, optionally including grinding and polishing your own optics, join the Amateur Telescope Makers mailing list.
"Also out in public beta is iTools, an Apache Port, that looks to have all the goodies like sendmail, DNS, and SSL"
Not quite. Apache, sendmail, dns, OpenSSH; it's already there in the OS X public beta standard installation. iTools is merely a configuration tool for the aforementioned software.
As a software developer for the Dutch Robocup team, I participated in the European Robocup Championship. The winners of last year's Robocup World Cup were the Iranian team, who were invited to join the european championship, which they also won.
Their low-budget hardware design (mostly plastics and wood) was very ingenious: because of the way the wheels turned, the robot was able to rotate around a point some 30 centimeters in front of the robot, where the ball would be. This made it possible to make fast turns without losing the ball.
The vision system used ordinary VHS videocameras, in which they actually put a tape to be able to analyze the game later on. The brains of these bots were motherboards of old '386 desktop machines, running MS-DOS and the soccer software off of a single high-density floppy drive! No team scored a goal against the Iranian team.
The robot I've worked on for the dutch team ran a rather bloated RedHat 6.2 distro on an on-board pentium (don't remember the exact specs). We had a wavelan wireless ethernet interface to communicate with the robot, and to view the diagnostics interface when the robot was running. The software is written in C++. The software uses different layered behaviours, not unlike Rodney Brooks' subsumption architecture. When the conditions for a certain behaviour are met, the behaviour takes control of the actuators. For example, there is an 'emergencybrake' behaviour that sets the speed of the wheels to 0 when the robot suddenly sees an object (other than the ball) in front of it. Other behaviours include driving around looking for the ball and scoring a goal. The software had some problems, mainly because before the tournament, we haven't been able to test the robot in an actual soccer game, but these were mostly fine-tuning problems in the behaviours. The overall architecture worked very well.
> Apple stopped selling Mac OS X Server a week or so ago. It's officially end-of-lifed.
No it's not! Check your facts. It's just temporarily unavailable because quality assurance tests of OSXs running on the new G4s aren't complete yet. The fact that it's not on apple's website doesn't mean you can't order it.
Why do people panic so much without reason? The OS X (server) developers' and administrators' lists are flooded with "aaargh no more os x server" messages. Just wait a few weeks and it'll be there again.
Apple is commited to the Mac admins and their servers. In fact, they're busy with the next version of the fileserver (sort of AppleShare IP running on OS X Server), as a call for selected test sites was made by Apple on the OS X Server admin list. The transition from OS X Server to OS X plus server tools will be fairly smooth, I bet.
gerti
They're off by default. In fact, in the installer assistant, there's an option to (dis)allow network access. In the Preferences application, all services can be turned on and off with radio buttons. Any clueless user will have trouble securing their box regardless of the OS. OS X will proably be as vulnerable as most BSDs: It's probably more vulnerable than the old MacOS (because it's a unix), but that's nothing compared to black orified, Outlook using, ActiveX-enabled macro-virus ridden windoze boxes.
If I type "console" at the login window, that's just what I get: a text-only session at the console. Also, by editing the init scripts, you can prevent the Window Manager from starting.
Moreover, ssh runs pretty fine, so remote administration is not really a problem. Besides, Apple's current server software (Netboot server and Macintosh Manager server on OS X Server and Appleshare IP on Mac OS 9) come with GUI remote admin tools. Also, the afpserver (afp = apple filing protocol) on OS X Server is configurable through a web/java based interface. I've used this for over a year on four Mac servers (two OS X Servers, two MacOS 9) and it works fine.
gertiThe kernel is not proprietary. In fact, the complete, functional core OS, called Darwin, is open source:
http://publicsource.apple.com
From what I've read on the Darwin developers' list, there's already an X server running on it, and the Intel port is booting.
Eventually, there won't be an OS X Server. There'll just be an OS X with extra server apps (Netboot server and File server, most importantly).
It's worth noting that although OS X will be a consumer OS, familiar unix services like telnet, sendmail (or postfix, of course), ftp and nfs are installed, and ssh compiles out of the box.
I'm not worried about developers writing for *nix and not for OS X.
M$ already has IE 5 shipping with the latest developer preview of OS X, and they will release Office: from what I heard, they're not just porting it from the current MacOS port, they're redoing it in Cocoa, the NeXTStep based (and most kick-ass of all) OS X API.
Other popular software will also be available for OS X, as http://www.apple.com/macosx/apps.html shows. Adobe, Microsoft, ID, Quark and others are listed on that page. Because publishing too much OS X info, particularly screenshots, is not yet possible because of non-disclosure agreements, the software companies will wait until the release of the public beta of OS X in september before they start releasing their OS X based beta's. However, pages like Version Tracker (with a MacOS background) and Softrak (with a NeXT background) already list a fair amount of OS X software, ready to download.
My bet is that there will be a large amount of software for OS X, and there are (at least) four reasons why:
For some excellent technical info on the upcoming OS X, take a look at the reviews Ars Technica did here.
gerti
--"To invent, you need a good imagination and a pile of junk" - Thomas Edison
Actually, configuration files for applications are stored in the ~/Library/Preferences directory. These preferences files are/should be in the PropertyList format: XML files with the 'plist' doctype, using the PropertyList DTD.
Some applications store other stuff in the ~/Library directory. Since some/most applications are stored at locations where mere mortals have no write access (/Local/Applications, /System/Applications and /Network/Applications), the users' config files can't be stored in the .app bundle.
NetInfo typically stores stuff like users/groups, network configuration, printers, services, etcetera. Stuff you would ordinarily assume to be in the /etc directory. The lookupd and netinfod processes serve information from the NetInfo databases to anyone who needs it. When NetInfo doesn't work for some reason, the system can fall back to information in /etc. The NetInfo database itsself is stored in /etc/netinfo/domain.nidb/
The beauty of NetInfo is that it's a distributed database: Machines on a network can connect to a NetInfo server to synchronise and share their configurations.
There's also a gui Preferences application to configure things like monitor settings, date and time, apps to start at login, etcetera.
More information about Netinfo is available here:
http://til.info.apple.com/tech info.nsf/artnum/n60038
At the lab I'm working as a system administrator, we're jumping with joy as we see the number of companies that suffer from this virus grow. We're using iMacs, OS X server Macs, and suns running Solaris boxes, and everything is perfectly allright here :-))
> These things have been in common use since the 70's when they ran the first Macs.
//e and the Apple //c, used a 65C02 cpu. Lots of people put a z80 card in one of the Apple ]['s expansion slots, so you could run cp/m as well (the Apple ][ user could choose DOS 3.3, ProDOS, USCD Pascal and CP/M as an OS).
The first Mac was released in April 1984. In the late 70's ('79 if I'm correct), the Apple ][ (two) and Apple ][+ were very popular machines, the first home computers to have colour graphics. These machines used the 6502 processor.
Later Apples, the Apple
The first Macs used the Motorola 68000, later Macs had 68020, 68030 or 68040 processors. Unfortunately, in lots of late-68K Macs, Apple put 68LC040s, a 68040 without a copro. The problem with early models of the 68LC040 is that copro emulation wouldn't work due to a bug in the cpu that would destroy the stack pointer. a Bad Thing(tm) indeed.
Now if you'll excuse me, I suffer from acute nostalgia. I'm off to do some vintage computing on one of my Apple ]['s.