Does anyone know if the new MacBook Pros will support the apt-get tools in the Fink distribution for OS X? I avoided the last revision because I read that the Core Duo CPU didn't have full hardware support for apt-get package management in the OS X Fink tools. I hope this has changed with the new Core 2 Duo chips. I'd like to apt-get install a MacBook Pro right now!
Normally I'm a pretty hardcore Debian user, but at my current contract job at a fairly major publishing house, I've been dealing with quite a lot of Mac systems. While OS X still has a ways to go before I would consider replacing my trusty Debian desktop, things like iTunes Music Store (iTMS) and the relatively recent addition of iTunes music videos and TV downloads really make the switch worth considering. But if only iTMS could come to Debian!!!
While writing a little multithreaded print workflow app in AppleScript for the client, I struck upon an idea: what if I could expose the functions of iTunes using AppleScript in a client/server type arrangement, and then make those functions accessible across the network to a Debian system running a modified dselect iTunes browser? AppleScript is pretty powerful, as any seasoned Mac user will attest, so it was quick work to create a handy little mutithreaded fully re-entrant AppleScript based server for the core iTunes functions (load song, play song, browse playlist, buy song, video clip etc).
The next part was to patch dselect on the Linux side so it could connect to my AppleScript server/wrapper on the Mac. I'd previously extended dselect with a Scheme-scriptable plugin, so it only took me a day or two to modify dselect with some Scheme macros so that it emulated to look and feel of iTunes (using ASCII art of course!!), but accessing the actual iTMS functions though the network exposed AppleScript..errr..script.
It worked a treat!! It is now a simple matter of running dselect on my Debian box to browse the iTMS, as long as the Mac over in the corner running the AppleScript wrapper is turned on of course. I have actually implemented a direct USB->USB cross over connection to get around bottlenecking problems with our Ethernet so I don't have to put up with skipping in iTMS MP3 or MPEG4 video playback. Now it works great!!!
The final step will be to patch apt-get with iTMS interface functionality...then buying my favorite music and TV shows legally will only be an apt-get install Justin-Timberlake or apt-get upgrade Desperate-Housewives away!
Which is nice.
The study of how memories are actually formed in the human brain, and neurobiology/neurochemistry in general have undergone massive leaps forward in the past 10 - 20 years. Articles like this one not only highlight to the general public how far neuroscience has come recently, but also that it may be creating more questions than it provides answers. Apart from the intriguing neurochemical consequences of using beta-blockers to modulate memory formation, there are no doubt significant ethical and legal issues which arise. Indeed, it is not difficult to imagine some of the complications associated with interfering with a process such as post-traumatic stress disorder (PTSD) which is not yet fully characterized at a psychological or neurochemical level.
A recent experience at my workplace accentuated how much more we have to learn about PTSD and what the ramifications of biochemically tampering with it might be. Late one night, a few months back, I got a panicked call on my cell phone from one of the junior system administration staff. He informed me that an electrical fire had broken out in the server room, that the halon fire system wasn't responding, and that the whole server room was on the verge of going up in flames. I tried to calm him (we had a good set up backups offsite), asked him to grab my treasured coffee mug with the vi command set printed on it, and to exit the building in a orderly fashion. As soon as he'd done that, I called the fire department, jumped in my car and drove to the office.
By the time I had arrived the firemen had the situation under control (the halon system had eventually kicked in), but my junior was sitting out in the carpark staring straight ahead, not really responding to any stimulus or being terribly coherent. I asked one of the firemen to fill my vi mug with some hot coffee they'd brought with them, got my junior sipping from the mug, and started to get some sense from him. After speaking with him for a while, I determined that the best way for him to deal with the trauma of almost being burned alive (and losing his bosses ' vi mug) was to get him back to work as quickly as possible.
I took him through to another part of the building unaffected by the fire where we kept some backup server systems. I asked him to rebuild and reconfigure our main file server as quickly as possible. Unfortunately it was quite out of date, so he needed to upgrade several of the packages before it was production ready. I left him to it, and went back outside to discuss the events of the evening with the fire department (and to refill my vi mug).
Around 20 minutes later, I went to check on my junior. Incredibly, he'd already completed the server upgrade and had the system online. I asked him how he had managed the feat so quickly. After all, there would be many dependencies to manage, and several packages would need to be manually configured and cross-checked from a variety of download sites. All he could say was 'apt-get...apt-get took care of it' as he rocked back and forth. It seemed that an entire portion of his memory from the previous 20 minutes had been erased, or more likely, never 'recorded' in his brain. He simply had no memory of having to manage complex dependencies! There was no mental archive of scouring download sites for appropriate libraries! It was like it had all just happened...automatically.
Needless to say, the incident scared me a little, and was a graphic illustration of not only the awesome power of apt-get, but also how little we understand of post traumatic stress disorder. Are we really in a position to start tampering with brain chemistry as such a fundamental level? Will valuable subconscious information be lost by using these drugs? Is it possible to remember all of the apt-get command switches accurately while under the influence of PTSD suppressing beta blockers? I certainly look forward to the community's response on this one!
Much attention has been lavished on new top-level domains as a method of differentiating certain types of content. For example, the.biz TLD is aimed at purely business-related sites (unlike the highly diluted.com), and.xxx has been proposed as a 'sandbox' to corral various adult content away from innocent eyes.
Software security is a very hot topic these days. Keeping up with a constant stream of security updates and patches is a tough enough job, but an added layer of risk and complexity is caused by the possibility of forged, hacked or trojaned software updates. If you can't be sure that the web site you are downloading your security patches from is 100% legitimate, how can you be sure that you aren't compromising your system every time you attempt to apply a security patch? A new TLD may be the solution
I envisage a new TLD where only approved security firms and software outfits would be allowed to register domain names. Basically any software download from one of these TLDs would be a guarantee that the patch is an official patch, and free from any potential hacks or 'pwnage'. As an example, I propose the formation of the.deb TLD. Sites able to be registered within the proposed.deb domain would maintain secure repositories of Debian packages, able to be downloaded by Debian users automatically using the apt-get tool. Users could rest assured that packages downloaded from a site in the.deb domain are fully vetted and checked and do not contain a trojan package. Similar TLDs could exist for Windows users (.vbx or.pif).
I look forward to the community's (and Vint Cerf's) comments!
The resignation of Bob Young is both surprising and saddening. Bob has arguably been one of the key figures responsible for the rise of Linux in corporate settings, complementing the technical nous of people like Linus Torvalds and Alan Cox, with an innovative and daring business model. The deep penetration of Linux into massive corporate entities such as IBM probably would not have happened as rapidly as it did without the pioneering advocacy work of Red Hat Inc, and Bob Young.
However, Bob's record hasn't been free of the odd black mark. Competition between the various Linux vendors for lucrative support contracts and bundling deals has often brought out the claws. For example, in 1999, a small group of anonymous users started posting extensively to the Debian discussion groups, claiming that Bruce Perens and Ian Murdoch actually used RPM on their Debian boxes to perform package administration, instead of apt-get, (which they also claimed was contaminated with IP belonging to an un-named x86 Unix vendor). The whole aim was to discredit these high profile individuals and have them forcibly removed from the Debian project. However, the whole scam backfired about 2 weeks later when the Debian list server admin revealed that the offending posts had originated from Red Hat's own network, and in fact were being sent directly from Bob Young's personal workstation, where he had concocted an apt-get driven script which automatically spammed the Debian mailing lists with pro-RPM FUD. Bob later admitted his part in the scheme in a Linux World interview in 2002, admitting that he had used a modified apt-get to "install packages of anti-Perens propaganda on the Debian mailing list server", and quoting "the superior ability of apt-get to deal with flamebait and troll dependencies over our own RPM tool". That particular story had a happy ending for the Debian commnunity fortunately, as Bruce Perens went on to have a highly successful career at HP, working as a LInux advocate.
Blogging is obviously big business, and stories like this one will only serve to stoke the fires out there in blogger land. The number of blogs is growing at an exponential rate, and with all things this popular, sorting the 'wheat from the chaff' is an increasingly difficult task. This is further complicated by the dynamic nature of blogs: once a quality blog has been discovered, how can an interested reader make sure they are up to date and have the most recent writings available to them? As one can imagine, the explosion of blog and bloggers out there has created a whole new realm of chaos. Try writing a blog about that!
While a number of solutions have been proposed to manage this situation, most of these are only in their early stages of development and do not fully address the problem. So let's look at the problem in detail and break it down. First of all, a type of centralized, searchable 'repository' of blogs needs to be created. This repository will contain descriptions of what each blog deals with, along with a suggested list of supplementary readings from linked blogs, or 'dependencies'. Ideally, the addresses of these repositories would be stored in a simple text file on the user's system, possibly in the/etc directory.
Secondly, a mechanism for managing the download of blog postings is required. Sometimes a blog posting may include graphics, sound files, and links to other blogs. This collection of data, or 'package', needs to be placed, or 'installed' onto the user's system so that they can actually view the posting.
Finally, a system for ensuring that blog posting packages are kept up to date and free of conflicts with other blog postings is needed. In essence, an Automatic Posting Tool (APT) is required to 'get' the blog postings. the 'apt-get' tool might even have a companion piece of software for graphically viewing and selecting subscribed blogs. For the purposes of this specification, it might be called 'bselect', for 'blog select'.
I think this pretty much wraps it up in terms of a basic specification. I now call upon the collective wisdom of the GNU/Slashdot crowd. What piece of software might possibly fulfill these requirements? Any suggestions? I look forward to the community's response!
Might the money wasted on the Shuttle and the ISS have been better spent on developing apt-get? It seems like a far more efficient method for delivering packages to the SPARCstation than a shuttle.
This story really reminds me of some work I did about 12 months ago back as a contractor in a large aerospace company. The problem they were facing at the time was a need to roll out an enterprise-wide VoIP system (management was actually quite clued-up about the potential of VoIP to empower E2E (employee to employee) communication), but there was a very heterogeneous mix of clients. Management used Windows, the engineers used Solaris and Irix the software developers used Linux, and the system administrators ran the whole back end on OS/390. There seemed to be no real solution to the problem: how to bring a solid VoIP system to all platforms, and preferably, one which was based around an open source platform. I could, however, see the solution where other's couldn't: apt-get.
Basically, apt-get is a kick-ass system for making sure your Debian system is up to date, has the latest packages installed, and manages conflicts. At the core, what is a VoIP system about? Making sure your voice 'packages' are up to date, have the latest messages 'installed', and manages conflicts, that is, a reply had been requested, yet hasn't been sent! All the key infrastructure was already in place, including an interface (dselect), which could easily be ported to all the required platforms to allow easy speaking and hearing of VoIP messages.
The first step was to use apt-get itself to distribute a modified apt.sources file, which contained the IP addresses of all of the VoIP clients on the network. Some people had suggested DNS as a solution to this, but my feeling was that DNS wouldn't scale so well (this was a large LAN, with over 10,000 clients...I'd like to see DNS cope with that!!). Once each client had it's apt.sources file updated, you could basically send a 'message' (your voice message, transcribed into a text file, and encapsulated into a.deb file by a custom packager I created that runs as a background process) to any host specified in the apt.sources file. To do this, I had to create a daemon-ized version of apt-get, listening on a predefined port. The daemon would be contacted by the apt-get client, would receive the.deb package containing the VoIP packet, and then 'install' it to the dselect based client on the receiving system.
Without trying to sound like I'm blowing my own trumpet, the system was a huge success, and the many features of apt-get for package management really came in handy for managing VoIP packet flows. For instance, just say you've just sent a message to a colleague via apt-get saying "Let's meet for lunch at 1pm". After transcribing your message into a special text file using an editor such as vi, you issue the command:
apt-get install host=fred-pc "Let's meet for lunch at 1pm"
But then...you're called into an emergency meeting and you can't make lunch until 2pm. You need to 'upgrade' your message to the latest version. After 'speaking' into the specially crafted VoIP microphone hardware (ie: transcribing with vi):
apt-get upgrade host=fred-pc "Make that 2pm!"
Easy! The whole project was essentially wrapped up in 6 months, and because of the open-source nature of apt-get, we'd managed to port to all of the platforms in our specification. If Microsoft can swallow their pride a little, I think they could really learn something from the power of apt-get! I look forward to the community's response! apt-get out.
While the actually hardware behind a successful Mars shot is undeniably critical, a similar amount of attention should be paid to human interface factors back at mission control. Mission controllers work long shifts, often without adequate sleep or food, and small mistakes on the ground can be fatal to the brave astronauts travelling through space, or walking on the surface of the Mars. The computer science community has conducted considerable work on human interfaces, but in my mind there is one which stands out above all others as an intuitive, easily understood and easy to use mission control interface: Debian's apt-get.
Ok ok...I understand some of you will be rolling your eyes at this stage, struggling to understand how on earth a piece of command line software designed for the installation and maintenance of Debian packages could even be remotely applicable to designing a robust mission control interface for missions to the Mars. I will explain. Basically, think of the Earth as a large Debian mirror, equipped with many astronaut 'files'. Imagine the space ship as a.deb package, safely protecting all the astronauts from the harsh vacuum of space. The Mars (or Mars...this solution is cross-platform after all) is your local host. The Sun is...well...that creaky old Sun Ultra 5 from yesterday's OSnews article that no one wants to go close to lest they get burned or flamed by Sun zealots. OK...now how does the system work?
Basically, a mission controller wants to 'install' a 'package' of astronauts from the Earth 'mirror' onto the Mars 'host'. It's 5am, the mission controller hasn't slept for 3 days, and every command sent from Houston is critical. Enter apt-get. The initial launch command would be something like:
apt-get install astronauts
Great! The launch vehicle is on its way! Since the 'link' between the 'mirror' and the 'host' is quite slow (imagine an old school 9600 baud leased line), the 'package' 'download' may take a few days to complete. This is where the mission control staff go to work on getting their Gentoo boxes compiling KDE. When the 'package' is 'downloaded', it's important to check that no astronauts were hurt along the way. The mission controller enters the following command:
apt-get check
This wil check for 'broken dependencies'. So far, so good! The '.deb package' will now successfully 'install' onto the 'host', meaning the astronauts can land on the Mars, and perform their critical experiments. However, all good things must come to and end, and the 'package' will need to be removed from the host. Mission control to the rescue.
apt-get remove astronauts
Excellent! Tom Hanks, Gary Sinese and that other guy are now on their way home. Again, this is a slow link, so our 'host' may take a few days to remove it from it's 'hard disk'. Once the capsule has landed back on Earth, it will be ready for the next group of astronauts to make their journey. But no-one would want to spend 10 days locked up in a small space filled with cast-off cans of Jolt Cola and empty Penguin Mint containers. The capsule will need to be tidied up! Mission control enters one last command to complete the mission:
apt-get autoclean
Done! Another successful Mars shot. Mission control is a breeze with the new apt-get mission control system. No more complicated GUIs, voice recognition or toggle switches. apt-get to infinity and beyond!
Tom, Tom, Tom. I was the administrator of Nortel's network for quite a few years, and let me tell you a little secret. We ran the whole thing on an 8-port 3Com 10BaseT hub, a 486SX/33 running Debian, and a whole stack of splicing wire and duct tape. You see, I started out like you. Plucky...confident...inexperienced. I'd run a small LAN. It was easy. 6 PCs? No problem! I'll just throw in this 8-port and away we go. I've got plenty of room for expansion (2 ports), and besides...10Mbit/sec ethernet should be plenty fast enough for years to come.
Sure enough, the little company that I'd joined soon grew and grew and grew. Soon, it was one of the largest telecoms suppliers in the world. So why didn't we just increase network capacity as we grew? Well...I was so confident with my little LAN that I formally requested that the networking budget be frozen until 2012. Imagine how silly I felt when I was trying to support a worldwide organisation of over 30,000 employees with an 8-port hub! There was only one thing I could do. Yes...splice the shit out of the ethernet cables coming out of the hub, and write some advanced packet management software to handle all the multiplexed data.
My mother had an old 486SX system in her basement that she'd stopped using several years ago since it was completely fucking obsolete, but for Nortel, it was the perfect hardware solution. The only thing missing was software. I thought about the problem at hand. What do I have? TCP/IP packets flying everywhere on CAT5 cables, spliced around 7,500 times over. What do I need to do? Manage those packets. What's another name for a packet? A PACKAGE! And what manages packages? apt-get, fuck you Tom...apt-get!!!!!
I spent the next few days furiously extending the source code to apt-get to deal with TCP/IP 'packages', as well as its native currency, the.deb package. It was no trivial feat. It required some very clever hardware tricks to get it to run at full speed on the ancient 486SX hardware, including full MMX, SSE and 3DNow! acceleration. I found out later that the Intel 486SX chip didn't actually support any of those instruction sets, so I had to spend an extra day writing an emulation layer.
No matter. By the end of the week, I had my new Debian/apt-get package management system in place, busily apt-get installing TCP/IP packages across our entire network. Of course, given the restrictions of our hardware, we were bound to come across minor slowdowns from time to time. And that's what you experienced Tom. And for that I'm sorry. I really am. I could have done better. My co-workers suggested I could have used Gentoo's 'emerge' system to better optimise those TCP/IP packets better to the 486SX system. Maybe I could have. But Tom...you have to understand...I only did it because I had to. You do understand that Tom...Tom? Are you still there Tom?
While this type of story may cause some initial alarm, it is hardly likely to cause any real damage to either Linux or the Open Source community. It is widely acknowledged (even by Linus himself) that the Linux kernel is due to the efforts of a wide group of contributors. A story trying to make it seem like Linus 'didn't do it all himself' is hardly going to shock anyone who is remotely familiar with the workings of the Linux community. Most likely this story will backfire in the faces of those perpetrating it, namely, the Alexis de Toqueville Institute, and it's backers, Microsoft.
This type of ill-informed FUD has been used in the past against the open source community without much real effect. For example, in 1999, a small group of anonymous users started posting extensively to the Debian discussion groups, claiming that Bruce Perens and Ian Murdoch actually used RPM on their Debian boxes to perform package administration, instead of apt-get, (which they also claimed was contaminated with IP belonging to an un-named x86 Unix vendor). The whole aim was to discredit these high profile individuals and have them forcibly removed from the Debian project. However, the whole scam backfired about 2 weeks later when the Debian list server admin revealed that the offending posts had originated from Red Hat's own network, and in fact were being sent directly from Bob Young's personal workstation, where he had concocted an apt-get driven script which automatically spammed the Debian mailing lists with pro-RPM FUD. Bob later admitted his part in the scheme in a Linux World interview in 2002, admitting that he had used a modified apt-get to "install packages of anti-Perens propaganda on the Debian mailing list server", and quoting "the superior ability of apt-get to deal with flamebait and troll dependencies over our own RPM tool". That particular story had a happy ending for the Debian commnunity fortunately, as Bruce Perens went on to have a highly successful career at HP, working as a LInux advocate.
I love reading about these kinds of large supercomputer projects...this is really cutting edge stuff, and in a way acts as a kind of 'crystal ball' for the types of high performance technologies that we might expect to see in more common server and workstation class machines in the next 10 years or so.
The article mentions that the new supercomputer will be used for non-classified projects. Does anyone have more exact details of what these projects may involve? Will it be a specific application, or more of a 'gun for hire' computing facility, with CPU cycles open to all comers for their own projects? It would be interesting to know what types of applications are planned for the supercomputer, as it may be possible to translate a raw measure of speed like the quoted '50 trillion calculations per second' into something more meaningful, like 'DNA base pairs compared per second', or 'weather cells simulated per hour'. Are there any specialists in these kinds of HPC applications who would like to comment? How fast do people think this supercomputer would run apt-get for instance? Would 50 trillion calculations per second equate to 50 trillion package installs per second? How long would it take to install all of Debian on this thing? Could the performance of the system actually be measured in Debian installs per second? I look forward to the community's response!
gay. This is a fact that much of the mainstream media glosses over in noting his accomplishments.
There are actually several mentions of Turing's sexual orientation within the linked article, including the horrendous treatment he received as a result of the increasingly open displays of his homosexuality he exhibited later in his life. It is a disgrace that such a key figure in the eventual overthrow of the Nazi regime (due to his contributions in cracking the Enigma code) could be subjected to such degrading mistreatment, not even ten years after the conclusion of the war.
What the article does not cover, however, is if Turing were alive today, would he prefer the elaborate menu-driven splendor of dselect, or the minimalist elegance of dpkg. That's what I would like to see the media pay some attention to.
I'm currently completing a degree in computer science, with only a few courses left to take before I graduate. Man, I wish I had read that article before last semester's 'Systems Programming and Optimization' course! It really puts a lot of things into perspective. So much of a programmer's time can get caught up in agonizing over low-level optimization. Worse than that are the weeks spent debating language and design choices with fellow programmers in a team. More often than not, these arguments boil down to personal biases against one language or another, due to perceived 'slowness', rather than issues such as 'will this language allow better design and maintenance of the code', or 'is a little slow actually fast enough'?
A particular illustration of this was in my last semester's 'Systems Programming and Optimization' course. The professor set us a project where we could choose an interesting subsystem of a Linux distro, analyze the code, and point out possible areas where it could be further optimized. I'm a pretty enthusiastic Debian user, so I chose to analyze the apt-get code. Our prof was very focused on low-level optimizations, so the first thing I did was to pull apart apt-get's Perl codebase and start to recode sections of it in C. At a mid-semester meeting, the professor suggested that I take it even further, and try using some SIMD/MMX calls in x86 assembly to parallelize package load calls.
This was a big ask, but me and my partner eventually had something working after a couple of weeks of slog. By this stage, apt-get was *flying* along. The final step of the optimization was to convert the package database to a binary format, using a series of 'keys' encoded in a type of database, or 'registry'. This sped up apt-get a further 25%, as calls to a machine-readable-only binary registry are technically superior to old fashioned text files (and XML was considered too slow)
Anyway, the sting in the tail (and I believe this is what the article highlights) was that upon submission of our project, we discovered that our professor had been admitted to hospital to have some kidney stones removed. In his place was another member of the faculty...but this time, a strong Gentoo supporter! He spent about 5 minutes reading over our hand-coded x86 assembly version of apt-get, and simply said "Nice work guys, but what I really want to see is this extended to include support for Gentoo's 'emerge' system...and for the code to run on my PowerMac 7600 Gentoo PPC box. You have a week's extension'
Needless to say, we were both freaking out. Because we had focused so heavily on optimization, we had sacrificed a lot of genericity in the code (otherwise we could have just coded up 'emerge' support as a plug-in for 'apt-get'), and also we had tied it to Intel x86 code. In the end we were both so burnt out that I slept for 2 days straight, and ended up writing the 'emerge' port in AppleScript in about 45 minutes. I told the new prof to just run it through MacOnLinux, which needless to say, he wasn't impressed with. I think it was because he had destroyed his old Mac OS 8 partition to turn it into a Gentoo swap partition. Anyway, me and my partner both ended up getting a C- for the course.
Let this be a lesson...read the article, and take it in. Optimization shouldn't be your sole focus. As Knuth once said, "premature optimisation is the root of all evil". Indeed Donald, indeed. Kind of ironic that Donald was the original professor in this story. I don't think he takes his work as seriously as he once did.
From my understanding of the Sasser worm, it infects vulnerable Windows PCs by probing and connecting through a specific open port, and then launching some Windows specific code designed to infect and propagate the worm. My question is of a largely theoretical, yet insightful nature: if a Linux machine is running a Windows emulation environment, such as WINE, and the Sasser specific port is open, is it possible that Sasser could attack and infect the Linux PC? After all, if WINE is at a level of compatibility which allows Linux users to run complex Win32 apps such as Microsoft Office, is it also not inconceivable that some Windows vulnerabilities have been emulated also? I look forward to the community's response.
While it is encouraging to see Linux certified hardware like the LC2210 laptop being sold, judging from the OSNews review it isn't all that much more Linux-compatible than a run of the mill Dell, IBM or Toshiba. To really lure new users across from the x86 or Macintosh worlds, a 'Linux certified' notebook needs to offer up a flawless experience. The notebook needs to wake instantly from sleep, 100% of the time. Wireless LAN needs to auto-detect nearby access points and automatically connect to them as required. And of course, video, sound, USB and FireWire all need to function without a new user ever having to edit, let alone be aware of the numerous/etc configuration files and kernel paramters necessary for these subsystems to work.
Anyways...as I said before, it's a good sign that companies are starting to make the effort to differentiate their notebook offerings on the basis of explicit Linux support, even if there is a little work that needs to be done yet. I am certainly interested in ordering one of these machines, as my old Dell Inspiron with a 500MHz Pentium III CPU running GNU/Debian Linux is certainly starting to show its age. I would still have a few questions about the LC2210's Debian compatibility though. Not mentioned in the review is the notebook's compatibility with apt-get, for instance. Do people think that I would be able to use apt-get without running into typical issues like robust ACPI support? Does anyone know what graphics chip this thing is using, and if so, would it work without screen corruption when using heavily GUI-oriented apps like dselect?
About 6 months ago I switched from a Dell running Linux to a 12" PowerBook. The attraction of Mac OS X's polished GUI, with all the raw power of UNIX available at the command prompt was too much of a temptation in the end. Of course I missed a lot of the software I used on my older Dell/Linux notebook, but these needs were well taken care of with the 'fink' software, which allows you to install many popular open source applications alongside Mac OS X.
So, my question is, alongside these great hardware updates just announced (12" PowerBook got bumped 33% to 1.33GHz!!!), has Apple updated any of the included software? I'm especially interested in things related to the Darwin UNIX core, or the Fink system. It'd be really great if Apple included a newer version of Fink, because the version of apt-get which was included with my 2003 12" PowerBook is a little out of date now. If apt-get has been updated, then I'll be getting my current PowerBook onto eBay, and I'll be ordering a new 1.33GHz 12" PowerBook tomorrow!
There are obviously financial advantages to a subscription model of software sales for a company like Sun...subscription revenue is received at known times, and in known amounts. It is not like the 'lumpy' type of revenue that is commonly associated with Sun's business, such as the sale of high-end servers, which occurs sporadically and is not easy to predict. So a move to subcription-based revenue will be of benefit to Sun in accounting terms.
But along with the benefits come disadvantages. Discounting customer objections, the biggest one is how to ensure that all Solaris installations are currently running on an up-to-date subscription license. It may be possible to have the Solaris servers 'call home' to check on licensing status, but some corporate servers are behind strong firewalls, and this may not work. Another method would be to have the central package manager control subscription licenses for individual pieces of sofware, including the Solaris kernel.
Basically, a company would purchase their Solaris subscription, and licenses for a number of other applications they wished to run. A packaging system, possibly something like a customised version of GNU/Debian's apt-get could be used to then manage the installation and tracking of the subscribed packages. apt-get would monitor the usage of the pieces of software against a crypt() encoded database of expiry dates and times. If an access was attempted to be made after the subscription period had expired, apt-get would automatically un-install the software, and the client would need to contact Sun to renew their subscription, and Sun would then send them fresh program tapes or diskettes. What do current Solaris admins and users think of this scheme? I look forward to hearing the community's response!
This article is great news for proponents of Linux in the Asian IT market. However, this is only a first step on the long march to acceptance. In my experience, a big stumbling block of new IT rollouts in non-Western environments are the language and alphabet related ones. These problems extend from the GUI and applications right at the top, all the way down to basic command line tools. Making sure that there are suitably localized versions of commonly used Open Source and GNU tools would be a great first step in the cultural revolution taking place in workplaces across Asia.
For example, the apt-get software is a key tool in the system administrator's arsenel. It has a relatively simple command line syntax, but it is obviously in English, and therefore would pose a problem for Japanese, Chinese or Korean administrators wanting to come rapidly up to speed. What would people think about tools like apt-get being re-engineered to include a language abstraction layer, so locales could be exchanged like plugins, to customise the tool for new countries? In fact, this type of localisation need not be limited merely to language changes. Entire cultural paradigms could be replicated via a plug-in system. For example, in Chinese markets the apt-get package management model could be described as a yum-cha cart, bringing tasty morsels of.deb packages to each table, or system. The package database would be the little card the attendant checks when you receive each plate, or in this case,.deb package
I look forward to the community's response!
How would Google manage a 100K-node cluster?
on
Speculating About Gmail
·
· Score: 5, Interesting
The Gmail project sounds like a fascinating experiment in massively distrubuted computing, and if anyone can pull it off, Google can. Obviously, a lot of custom software will need to be developed by Google's engineers to make a 100,000 node cluster fly. As mentioned in the article, distributed filesystem, RPC and network tracking software will be essential, and high priority projects. But what about the 'boring' nuts'n'bolts of keeping those cluster nodes in good shape? What about day to day administation tasks like adding new users, or checking disk usage? And what about keeping packages up to date?
When you stop to think about it, package management could be a key factor in the smooth running of the Google Gmail cluster. What software would be used to make sure each one of those 100,000 mail-handling nodes was running the latest, most secure version of sendmail, qmail or postfix? We know Google uses Linux extensively. It is fairly safe to assume that they are using apt-get to sling packages. But what do the Slashdot community think about apt-get's long term suitability for these types of projects? Can the open-source, Free Software package management poster child scale to meet the 100K-node challenge? I look forward to hearing the community's response!
You are correct Deraj. Even though the apt-get code is GPL'ed and therefore available for all to read, the majority of people miss a few subtle points in the source code. The assembly optimizations. The OpenGL hooks. The MP3 streaming capabilities. Instant messaging interfaces. Links to satellite tracking networks. I believe apt-get to be on par with such great open source works as the Linux kernel, Apache, and xbill. It is about the package format. It is about apt-get. It's about standing up and saying "Dammit, I'm sick of RPM not having any cluster management capabilities or Mac OS X Expose-like animations, I'm mad as hell AND I'M NOT TAKING IT ANY MORE!"
System administrators (especially UNIX sysadmins) probably spend a lot more time looking at console-type displays (eg: xterms, kterms, what have you) than other users, which means many hours a day looking at a stereotypically black little box with small white writing on it. That can really make your eyes tired. What type of display do sysadmins prefer? Once I started using a laptop for a lot of my work, I found it really difficult to go back to my CRT-based desktop at home. Terminal fonts just looked...fuzzy. Doing a lot of command line work on an LCD is a pleasure for the eyes. Are there any hardcore apt-get users out there willing to comment? If you need to spend a day with dselect upgrading your cluster or whatnot, do you prefer an LCD panel or a CRT? Or perhaps the new VRML apt-get interface and a pair of VR goggles?
Slashdot Mirror
Trying to add Token Ring support to my apt-get driven router of course!
Does anyone know if the new MacBook Pros will support the apt-get tools in the Fink distribution for OS X? I avoided the last revision because I read that the Core Duo CPU didn't have full hardware support for apt-get package management in the OS X Fink tools. I hope this has changed with the new Core 2 Duo chips. I'd like to apt-get install a MacBook Pro right now!
Normally I'm a pretty hardcore Debian user, but at my current contract job at a fairly major publishing house, I've been dealing with quite a lot of Mac systems. While OS X still has a ways to go before I would consider replacing my trusty Debian desktop, things like iTunes Music Store (iTMS) and the relatively recent addition of iTunes music videos and TV downloads really make the switch worth considering. But if only iTMS could come to Debian!!! While writing a little multithreaded print workflow app in AppleScript for the client, I struck upon an idea: what if I could expose the functions of iTunes using AppleScript in a client/server type arrangement, and then make those functions accessible across the network to a Debian system running a modified dselect iTunes browser? AppleScript is pretty powerful, as any seasoned Mac user will attest, so it was quick work to create a handy little mutithreaded fully re-entrant AppleScript based server for the core iTunes functions (load song, play song, browse playlist, buy song, video clip etc). The next part was to patch dselect on the Linux side so it could connect to my AppleScript server/wrapper on the Mac. I'd previously extended dselect with a Scheme-scriptable plugin, so it only took me a day or two to modify dselect with some Scheme macros so that it emulated to look and feel of iTunes (using ASCII art of course!!), but accessing the actual iTMS functions though the network exposed AppleScript..errr..script. It worked a treat!! It is now a simple matter of running dselect on my Debian box to browse the iTMS, as long as the Mac over in the corner running the AppleScript wrapper is turned on of course. I have actually implemented a direct USB->USB cross over connection to get around bottlenecking problems with our Ethernet so I don't have to put up with skipping in iTMS MP3 or MPEG4 video playback. Now it works great!!! The final step will be to patch apt-get with iTMS interface functionality...then buying my favorite music and TV shows legally will only be an apt-get install Justin-Timberlake or apt-get upgrade Desperate-Housewives away! Which is nice.
A recent experience at my workplace accentuated how much more we have to learn about PTSD and what the ramifications of biochemically tampering with it might be. Late one night, a few months back, I got a panicked call on my cell phone from one of the junior system administration staff. He informed me that an electrical fire had broken out in the server room, that the halon fire system wasn't responding, and that the whole server room was on the verge of going up in flames. I tried to calm him (we had a good set up backups offsite), asked him to grab my treasured coffee mug with the vi command set printed on it, and to exit the building in a orderly fashion. As soon as he'd done that, I called the fire department, jumped in my car and drove to the office.
By the time I had arrived the firemen had the situation under control (the halon system had eventually kicked in), but my junior was sitting out in the carpark staring straight ahead, not really responding to any stimulus or being terribly coherent. I asked one of the firemen to fill my vi mug with some hot coffee they'd brought with them, got my junior sipping from the mug, and started to get some sense from him. After speaking with him for a while, I determined that the best way for him to deal with the trauma of almost being burned alive (and losing his bosses ' vi mug) was to get him back to work as quickly as possible.
I took him through to another part of the building unaffected by the fire where we kept some backup server systems. I asked him to rebuild and reconfigure our main file server as quickly as possible. Unfortunately it was quite out of date, so he needed to upgrade several of the packages before it was production ready. I left him to it, and went back outside to discuss the events of the evening with the fire department (and to refill my vi mug).
Around 20 minutes later, I went to check on my junior. Incredibly, he'd already completed the server upgrade and had the system online. I asked him how he had managed the feat so quickly. After all, there would be many dependencies to manage, and several packages would need to be manually configured and cross-checked from a variety of download sites. All he could say was 'apt-get...apt-get took care of it' as he rocked back and forth. It seemed that an entire portion of his memory from the previous 20 minutes had been erased, or more likely, never 'recorded' in his brain. He simply had no memory of having to manage complex dependencies! There was no mental archive of scouring download sites for appropriate libraries! It was like it had all just happened...automatically.
Needless to say, the incident scared me a little, and was a graphic illustration of not only the awesome power of apt-get, but also how little we understand of post traumatic stress disorder. Are we really in a position to start tampering with brain chemistry as such a fundamental level? Will valuable subconscious information be lost by using these drugs? Is it possible to remember all of the apt-get command switches accurately while under the influence of PTSD suppressing beta blockers? I certainly look forward to the community's response on this one!
Software security is a very hot topic these days. Keeping up with a constant stream of security updates and patches is a tough enough job, but an added layer of risk and complexity is caused by the possibility of forged, hacked or trojaned software updates. If you can't be sure that the web site you are downloading your security patches from is 100% legitimate, how can you be sure that you aren't compromising your system every time you attempt to apply a security patch? A new TLD may be the solution
I envisage a new TLD where only approved security firms and software outfits would be allowed to register domain names. Basically any software download from one of these TLDs would be a guarantee that the patch is an official patch, and free from any potential hacks or 'pwnage'. As an example, I propose the formation of the .deb TLD. Sites able to be registered within the proposed .deb domain would maintain secure repositories of Debian packages, able to be downloaded by Debian users automatically using the apt-get tool. Users could rest assured that packages downloaded from a site in the .deb domain are fully vetted and checked and do not contain a trojan package. Similar TLDs could exist for Windows users (.vbx or .pif).
I look forward to the community's (and Vint Cerf's) comments!
However, Bob's record hasn't been free of the odd black mark. Competition between the various Linux vendors for lucrative support contracts and bundling deals has often brought out the claws. For example, in 1999, a small group of anonymous users started posting extensively to the Debian discussion groups, claiming that Bruce Perens and Ian Murdoch actually used RPM on their Debian boxes to perform package administration, instead of apt-get, (which they also claimed was contaminated with IP belonging to an un-named x86 Unix vendor). The whole aim was to discredit these high profile individuals and have them forcibly removed from the Debian project. However, the whole scam backfired about 2 weeks later when the Debian list server admin revealed that the offending posts had originated from Red Hat's own network, and in fact were being sent directly from Bob Young's personal workstation, where he had concocted an apt-get driven script which automatically spammed the Debian mailing lists with pro-RPM FUD. Bob later admitted his part in the scheme in a Linux World interview in 2002, admitting that he had used a modified apt-get to "install packages of anti-Perens propaganda on the Debian mailing list server", and quoting "the superior ability of apt-get to deal with flamebait and troll dependencies over our own RPM tool". That particular story had a happy ending for the Debian commnunity fortunately, as Bruce Perens went on to have a highly successful career at HP, working as a LInux advocate.
While a number of solutions have been proposed to manage this situation, most of these are only in their early stages of development and do not fully address the problem. So let's look at the problem in detail and break it down. First of all, a type of centralized, searchable 'repository' of blogs needs to be created. This repository will contain descriptions of what each blog deals with, along with a suggested list of supplementary readings from linked blogs, or 'dependencies'. Ideally, the addresses of these repositories would be stored in a simple text file on the user's system, possibly in the /etc directory.
Secondly, a mechanism for managing the download of blog postings is required. Sometimes a blog posting may include graphics, sound files, and links to other blogs. This collection of data, or 'package', needs to be placed, or 'installed' onto the user's system so that they can actually view the posting.
Finally, a system for ensuring that blog posting packages are kept up to date and free of conflicts with other blog postings is needed. In essence, an Automatic Posting Tool (APT) is required to 'get' the blog postings. the 'apt-get' tool might even have a companion piece of software for graphically viewing and selecting subscribed blogs. For the purposes of this specification, it might be called 'bselect', for 'blog select'.
I think this pretty much wraps it up in terms of a basic specification. I now call upon the collective wisdom of the GNU/Slashdot crowd. What piece of software might possibly fulfill these requirements? Any suggestions? I look forward to the community's response!
Might the money wasted on the Shuttle and the ISS have been better spent on developing apt-get? It seems like a far more efficient method for delivering packages to the SPARCstation than a shuttle.
Basically, apt-get is a kick-ass system for making sure your Debian system is up to date, has the latest packages installed, and manages conflicts. At the core, what is a VoIP system about? Making sure your voice 'packages' are up to date, have the latest messages 'installed', and manages conflicts, that is, a reply had been requested, yet hasn't been sent! All the key infrastructure was already in place, including an interface (dselect), which could easily be ported to all the required platforms to allow easy speaking and hearing of VoIP messages.
The first step was to use apt-get itself to distribute a modified apt.sources file, which contained the IP addresses of all of the VoIP clients on the network. Some people had suggested DNS as a solution to this, but my feeling was that DNS wouldn't scale so well (this was a large LAN, with over 10,000 clients...I'd like to see DNS cope with that!!). Once each client had it's apt.sources file updated, you could basically send a 'message' (your voice message, transcribed into a text file, and encapsulated into a .deb file by a custom packager I created that runs as a background process) to any host specified in the apt.sources file. To do this, I had to create a daemon-ized version of apt-get, listening on a predefined port. The daemon would be contacted by the apt-get client, would receive the .deb package containing the VoIP packet, and then 'install' it to the dselect based client on the receiving system.
Without trying to sound like I'm blowing my own trumpet, the system was a huge success, and the many features of apt-get for package management really came in handy for managing VoIP packet flows. For instance, just say you've just sent a message to a colleague via apt-get saying "Let's meet for lunch at 1pm". After transcribing your message into a special text file using an editor such as vi, you issue the command:
apt-get install host=fred-pc "Let's meet for lunch at 1pm"
But then...you're called into an emergency meeting and you can't make lunch until 2pm. You need to 'upgrade' your message to the latest version. After 'speaking' into the specially crafted VoIP microphone hardware (ie: transcribing with vi):
apt-get upgrade host=fred-pc "Make that 2pm!"
Easy! The whole project was essentially wrapped up in 6 months, and because of the open-source nature of apt-get, we'd managed to port to all of the platforms in our specification. If Microsoft can swallow their pride a little, I think they could really learn something from the power of apt-get! I look forward to the community's response! apt-get out.
Ok ok...I understand some of you will be rolling your eyes at this stage, struggling to understand how on earth a piece of command line software designed for the installation and maintenance of Debian packages could even be remotely applicable to designing a robust mission control interface for missions to the Mars. I will explain. Basically, think of the Earth as a large Debian mirror, equipped with many astronaut 'files'. Imagine the space ship as a .deb package, safely protecting all the astronauts from the harsh vacuum of space. The Mars (or Mars...this solution is cross-platform after all) is your local host. The Sun is...well...that creaky old Sun Ultra 5 from yesterday's OSnews article that no one wants to go close to lest they get burned or flamed by Sun zealots. OK...now how does the system work?
Basically, a mission controller wants to 'install' a 'package' of astronauts from the Earth 'mirror' onto the Mars 'host'. It's 5am, the mission controller hasn't slept for 3 days, and every command sent from Houston is critical. Enter apt-get. The initial launch command would be something like:
apt-get install astronauts
Great! The launch vehicle is on its way! Since the 'link' between the 'mirror' and the 'host' is quite slow (imagine an old school 9600 baud leased line), the 'package' 'download' may take a few days to complete. This is where the mission control staff go to work on getting their Gentoo boxes compiling KDE. When the 'package' is 'downloaded', it's important to check that no astronauts were hurt along the way. The mission controller enters the following command:
apt-get check
This wil check for 'broken dependencies'. So far, so good! The '.deb package' will now successfully 'install' onto the 'host', meaning the astronauts can land on the Mars, and perform their critical experiments. However, all good things must come to and end, and the 'package' will need to be removed from the host. Mission control to the rescue.
apt-get remove astronauts
Excellent! Tom Hanks, Gary Sinese and that other guy are now on their way home. Again, this is a slow link, so our 'host' may take a few days to remove it from it's 'hard disk'. Once the capsule has landed back on Earth, it will be ready for the next group of astronauts to make their journey. But no-one would want to spend 10 days locked up in a small space filled with cast-off cans of Jolt Cola and empty Penguin Mint containers. The capsule will need to be tidied up! Mission control enters one last command to complete the mission:
apt-get autoclean
Done! Another successful Mars shot. Mission control is a breeze with the new apt-get mission control system. No more complicated GUIs, voice recognition or toggle switches. apt-get to infinity and beyond!
I had some downtime while the 486SX rebooted.
Sure enough, the little company that I'd joined soon grew and grew and grew. Soon, it was one of the largest telecoms suppliers in the world. So why didn't we just increase network capacity as we grew? Well...I was so confident with my little LAN that I formally requested that the networking budget be frozen until 2012. Imagine how silly I felt when I was trying to support a worldwide organisation of over 30,000 employees with an 8-port hub! There was only one thing I could do. Yes...splice the shit out of the ethernet cables coming out of the hub, and write some advanced packet management software to handle all the multiplexed data.
My mother had an old 486SX system in her basement that she'd stopped using several years ago since it was completely fucking obsolete, but for Nortel, it was the perfect hardware solution. The only thing missing was software. I thought about the problem at hand. What do I have? TCP/IP packets flying everywhere on CAT5 cables, spliced around 7,500 times over. What do I need to do? Manage those packets. What's another name for a packet? A PACKAGE! And what manages packages? apt-get, fuck you Tom...apt-get!!!!!
I spent the next few days furiously extending the source code to apt-get to deal with TCP/IP 'packages', as well as its native currency, the .deb package. It was no trivial feat. It required some very clever hardware tricks to get it to run at full speed on the ancient 486SX hardware, including full MMX, SSE and 3DNow! acceleration. I found out later that the Intel 486SX chip didn't actually support any of those instruction sets, so I had to spend an extra day writing an emulation layer.
No matter. By the end of the week, I had my new Debian/apt-get package management system in place, busily apt-get installing TCP/IP packages across our entire network. Of course, given the restrictions of our hardware, we were bound to come across minor slowdowns from time to time. And that's what you experienced Tom. And for that I'm sorry. I really am. I could have done better. My co-workers suggested I could have used Gentoo's 'emerge' system to better optimise those TCP/IP packets better to the 486SX system. Maybe I could have. But Tom...you have to understand...I only did it because I had to. You do understand that Tom...Tom? Are you still there Tom?
...be available via apt-get?
This type of ill-informed FUD has been used in the past against the open source community without much real effect. For example, in 1999, a small group of anonymous users started posting extensively to the Debian discussion groups, claiming that Bruce Perens and Ian Murdoch actually used RPM on their Debian boxes to perform package administration, instead of apt-get, (which they also claimed was contaminated with IP belonging to an un-named x86 Unix vendor). The whole aim was to discredit these high profile individuals and have them forcibly removed from the Debian project. However, the whole scam backfired about 2 weeks later when the Debian list server admin revealed that the offending posts had originated from Red Hat's own network, and in fact were being sent directly from Bob Young's personal workstation, where he had concocted an apt-get driven script which automatically spammed the Debian mailing lists with pro-RPM FUD. Bob later admitted his part in the scheme in a Linux World interview in 2002, admitting that he had used a modified apt-get to "install packages of anti-Perens propaganda on the Debian mailing list server", and quoting "the superior ability of apt-get to deal with flamebait and troll dependencies over our own RPM tool". That particular story had a happy ending for the Debian commnunity fortunately, as Bruce Perens went on to have a highly successful career at HP, working as a LInux advocate.
The article mentions that the new supercomputer will be used for non-classified projects. Does anyone have more exact details of what these projects may involve? Will it be a specific application, or more of a 'gun for hire' computing facility, with CPU cycles open to all comers for their own projects? It would be interesting to know what types of applications are planned for the supercomputer, as it may be possible to translate a raw measure of speed like the quoted '50 trillion calculations per second' into something more meaningful, like 'DNA base pairs compared per second', or 'weather cells simulated per hour'. Are there any specialists in these kinds of HPC applications who would like to comment? How fast do people think this supercomputer would run apt-get for instance? Would 50 trillion calculations per second equate to 50 trillion package installs per second? How long would it take to install all of Debian on this thing? Could the performance of the system actually be measured in Debian installs per second? I look forward to the community's response!
There are actually several mentions of Turing's sexual orientation within the linked article, including the horrendous treatment he received as a result of the increasingly open displays of his homosexuality he exhibited later in his life. It is a disgrace that such a key figure in the eventual overthrow of the Nazi regime (due to his contributions in cracking the Enigma code) could be subjected to such degrading mistreatment, not even ten years after the conclusion of the war.
What the article does not cover, however, is if Turing were alive today, would he prefer the elaborate menu-driven splendor of dselect, or the minimalist elegance of dpkg. That's what I would like to see the media pay some attention to.
A particular illustration of this was in my last semester's 'Systems Programming and Optimization' course. The professor set us a project where we could choose an interesting subsystem of a Linux distro, analyze the code, and point out possible areas where it could be further optimized. I'm a pretty enthusiastic Debian user, so I chose to analyze the apt-get code. Our prof was very focused on low-level optimizations, so the first thing I did was to pull apart apt-get's Perl codebase and start to recode sections of it in C. At a mid-semester meeting, the professor suggested that I take it even further, and try using some SIMD/MMX calls in x86 assembly to parallelize package load calls.
This was a big ask, but me and my partner eventually had something working after a couple of weeks of slog. By this stage, apt-get was *flying* along. The final step of the optimization was to convert the package database to a binary format, using a series of 'keys' encoded in a type of database, or 'registry'. This sped up apt-get a further 25%, as calls to a machine-readable-only binary registry are technically superior to old fashioned text files (and XML was considered too slow)
Anyway, the sting in the tail (and I believe this is what the article highlights) was that upon submission of our project, we discovered that our professor had been admitted to hospital to have some kidney stones removed. In his place was another member of the faculty...but this time, a strong Gentoo supporter! He spent about 5 minutes reading over our hand-coded x86 assembly version of apt-get, and simply said "Nice work guys, but what I really want to see is this extended to include support for Gentoo's 'emerge' system...and for the code to run on my PowerMac 7600 Gentoo PPC box. You have a week's extension'
Needless to say, we were both freaking out. Because we had focused so heavily on optimization, we had sacrificed a lot of genericity in the code (otherwise we could have just coded up 'emerge' support as a plug-in for 'apt-get'), and also we had tied it to Intel x86 code. In the end we were both so burnt out that I slept for 2 days straight, and ended up writing the 'emerge' port in AppleScript in about 45 minutes. I told the new prof to just run it through MacOnLinux, which needless to say, he wasn't impressed with. I think it was because he had destroyed his old Mac OS 8 partition to turn it into a Gentoo swap partition. Anyway, me and my partner both ended up getting a C- for the course.
Let this be a lesson...read the article, and take it in. Optimization shouldn't be your sole focus. As Knuth once said, "premature optimisation is the root of all evil". Indeed Donald, indeed. Kind of ironic that Donald was the original professor in this story. I don't think he takes his work as seriously as he once did.
From my understanding of the Sasser worm, it infects vulnerable Windows PCs by probing and connecting through a specific open port, and then launching some Windows specific code designed to infect and propagate the worm. My question is of a largely theoretical, yet insightful nature: if a Linux machine is running a Windows emulation environment, such as WINE, and the Sasser specific port is open, is it possible that Sasser could attack and infect the Linux PC? After all, if WINE is at a level of compatibility which allows Linux users to run complex Win32 apps such as Microsoft Office, is it also not inconceivable that some Windows vulnerabilities have been emulated also? I look forward to the community's response.
Anyways...as I said before, it's a good sign that companies are starting to make the effort to differentiate their notebook offerings on the basis of explicit Linux support, even if there is a little work that needs to be done yet. I am certainly interested in ordering one of these machines, as my old Dell Inspiron with a 500MHz Pentium III CPU running GNU/Debian Linux is certainly starting to show its age. I would still have a few questions about the LC2210's Debian compatibility though. Not mentioned in the review is the notebook's compatibility with apt-get, for instance. Do people think that I would be able to use apt-get without running into typical issues like robust ACPI support? Does anyone know what graphics chip this thing is using, and if so, would it work without screen corruption when using heavily GUI-oriented apps like dselect?
I look forward to the community's response!!
So, my question is, alongside these great hardware updates just announced (12" PowerBook got bumped 33% to 1.33GHz!!!), has Apple updated any of the included software? I'm especially interested in things related to the Darwin UNIX core, or the Fink system. It'd be really great if Apple included a newer version of Fink, because the version of apt-get which was included with my 2003 12" PowerBook is a little out of date now. If apt-get has been updated, then I'll be getting my current PowerBook onto eBay, and I'll be ordering a new 1.33GHz 12" PowerBook tomorrow!
I look forward to the community's response!
But along with the benefits come disadvantages. Discounting customer objections, the biggest one is how to ensure that all Solaris installations are currently running on an up-to-date subscription license. It may be possible to have the Solaris servers 'call home' to check on licensing status, but some corporate servers are behind strong firewalls, and this may not work. Another method would be to have the central package manager control subscription licenses for individual pieces of sofware, including the Solaris kernel.
Basically, a company would purchase their Solaris subscription, and licenses for a number of other applications they wished to run. A packaging system, possibly something like a customised version of GNU/Debian's apt-get could be used to then manage the installation and tracking of the subscribed packages. apt-get would monitor the usage of the pieces of software against a crypt() encoded database of expiry dates and times. If an access was attempted to be made after the subscription period had expired, apt-get would automatically un-install the software, and the client would need to contact Sun to renew their subscription, and Sun would then send them fresh program tapes or diskettes. What do current Solaris admins and users think of this scheme? I look forward to hearing the community's response!
For example, the apt-get software is a key tool in the system administrator's arsenel. It has a relatively simple command line syntax, but it is obviously in English, and therefore would pose a problem for Japanese, Chinese or Korean administrators wanting to come rapidly up to speed. What would people think about tools like apt-get being re-engineered to include a language abstraction layer, so locales could be exchanged like plugins, to customise the tool for new countries? In fact, this type of localisation need not be limited merely to language changes. Entire cultural paradigms could be replicated via a plug-in system. For example, in Chinese markets the apt-get package management model could be described as a yum-cha cart, bringing tasty morsels of .deb packages to each table, or system. The package database would be the little card the attendant checks when you receive each plate, or in this case, .deb package
I look forward to the community's response!
When you stop to think about it, package management could be a key factor in the smooth running of the Google Gmail cluster. What software would be used to make sure each one of those 100,000 mail-handling nodes was running the latest, most secure version of sendmail, qmail or postfix? We know Google uses Linux extensively. It is fairly safe to assume that they are using apt-get to sling packages. But what do the Slashdot community think about apt-get's long term suitability for these types of projects? Can the open-source, Free Software package management poster child scale to meet the 100K-node challenge? I look forward to hearing the community's response!
I look forward to the community's reponse.
System administrators (especially UNIX sysadmins) probably spend a lot more time looking at console-type displays (eg: xterms, kterms, what have you) than other users, which means many hours a day looking at a stereotypically black little box with small white writing on it. That can really make your eyes tired. What type of display do sysadmins prefer? Once I started using a laptop for a lot of my work, I found it really difficult to go back to my CRT-based desktop at home. Terminal fonts just looked...fuzzy. Doing a lot of command line work on an LCD is a pleasure for the eyes. Are there any hardcore apt-get users out there willing to comment? If you need to spend a day with dselect upgrading your cluster or whatnot, do you prefer an LCD panel or a CRT? Or perhaps the new VRML apt-get interface and a pair of VR goggles?