RedHat's 'trial by fire' approach for their new security policy is a good one, and is something all distro makers should try. Nothing beats having your default security config probed and tested by the world's best crackers in a real life environment. But network security is only one piece of the puzzle. As the Windows community has demonstrated time and time again, trojans and spyware can be just as dangerous from a security point of view as network exploits. And while the problem may not be as severe on Linux due to the separation of the root user from the average day-to-day account, havoc may still be wreaked by a regular user downloading a package and installing it, and thus inadvertently installing a trojan.
It seems to me that our package managers (used by the majority of Linux users...not everyone compiles from source) are vulnerable to some type of subversion. They are not controlled or vetted by a central authority. There is no 'certificate' which can be attached to them to guarantee their purity. What the Linux community needs, I feel, is a type of central signing authority or cryptographically sealed DRM-compatible package management system. This could eliminate potential threats associated with trojaned Linux packages. Imagine a secure apt-get. Packages would be enveloped in a tough layer of crypt() security. They would be digitally signed by the Debian project manager, or even Ian Murdock for highly critical packages like the kernel. And it would be impossible to accidently load and install a trojan. Apt-get could even be modified to 'phone home' and let the Debian administrators know which packages where the most popular (and make security updating easier!) packages were being installed and to automatically e-mail users with news of package updates and 'special offers' from co-sponsors. I look forward to the community's response!
Often these types of vulnerabilities only affect one platform (and usually Windows), but does anyone know which platforms are affected by this new exploit? Mac OS X and Linux too? Does it make any difference if I used apt-get to install the RealPlayer binary instead of the Real packaged one? I'm in the middle of sealing off RealPlatyer ports on all our organization's firewalls at the moment, but a lot of them are running OpenBSD and we're having trouble keeping them up long enough to edit the firewall config files.
For the purposes of teaching computer architecture, assembly language may be just the ticket. But out there in the 'real world', assembly language is usually limited to 'embedded' type systems, and for small sections of absolutely performance critical code where a developer must make use of absolutely every last CPU feature and nuance to really wring extra oomph from their code. However, with a fresh crop of graduate students becoming more familiar with assembly, might we see a return to the 'good old days' where a lot more software was developed in assembler? Could anyone foresee a day when a major open source project, such as the Linux kernel or Apache, is recoded in assembly to really boost overall performance beyond those levels able to be achieved by compilers such as gcc? I for one would love to see an MMX/SSE optimized version of apt-get built in hand-tuned x86 assembler...vectorization of package installs would be the killer app for me.
Could anyone comment on the use of assembly in major open source projects? Is there any now? Will its use increase to take advantage of vector units and the like? What about cross-platform assembler? Could we one day see an assembly dialect with the traditional 'raw' access to the machine which hard core developers love, coupled with a Java-like virtual machine for cross platform compatibility? I look forward to the community's response!
OpenBSD crashes: how could it have been prevented?
on
Remotely Crash OpenBSD
·
· Score: 1, Troll
This is a serious issue especially given the large number of OpenBSD firewall machines which are in service across the internet. While possibly not a direct security threat, remote crash exploits are obviously highly disruptive and in today's networked economy, highly costly in terms of lost productivity. It's good to see, however, the rapid response of th BSD community to this threat.
I was talking with some of my colleagues in network security this morning about the OpenBSD exploit and means by which future exploits may be avoided. One suggestion which was raised was that the OpenBSD 'ports' system may be to blame. After all, if you need to add packages on a BSD system, 'ports' must be opened, and when ports are open on firewall boxes, bad things happen. Debian's apt-get system for example does not require 'ports' to work properly, and therefore may be immune from this type of exploit. Is this a possible solution? I look forward to hearing the community's responses!
My hope is that the Groklaw project will pay sufficient attention to the GNU/Debian Linux distribution due to its historically important position as a Linux distribution truly dedicated to remaining 'free', and operating within the bounds of a clearly spelled out social contract. These features, as well as the fact that GNU/Debian is maintained not by a corporate entity, but by volunteers, make it worthy of a special mention in the history of Linux. In addition, I would like to see a line-by-line historical commentary on the CVS commit logs for apt-get. That would be great.
Beowulf-ready Linux distros for chess computers?
on
Chess - 2070 CPUs vs 1 GM
·
· Score: -1, Offtopic
This story reminds me of the frenzied Beowulf-mad days of a few years ago when it seemed every second story on Slashdot was about the rollout of a new Beowulf cluster somewhere (and of course spawned the '..imagine a Beowulf cluster of these' meme). Eventually, a few Beowulf customised Linux distros emerged, such as Scyld Linux, but you don't hear too much about these distros any more.
Which leads me to my question: Has anyone had any experience with these 'cluster ready' distros? Have they used them for the type of rollout described in the article (ie: chess-playing supercomputer)? What are your opinions on the package management included in the distribution, ie: does it make it easy to load packages onto several hundred nodes in a coordinated fashion? Would a massively distributed version of apt-get be a suitable solution in this problem space? Would it be possible to meta-manage a Beowulf cluster by using a massive distributed/parallel genetic algorithm to autonomously develop a distributed apt-get manager rather than tie up precious Debian developer resources? What could happen if apt-get developed a kind of primitive sentience, backed by a 256-node Beowulf cluster? I look forward to the community's feedback!
The story about Portland being a hotbed of Linux activism and getting a lot of new users into the community reminded me of a recent experience. I just built an Athlon XP PC for a friend who needed a cheap system just for the standard sort of computing tasks, you know, web, e-mail, some word processing and maybe a bit of light package management. Of course the finishing touch to a nice, budget Athlon XP was going to be Debian, with Mozilla for web/e-mail and OpenOffice.org to take care of office needs. But when it was time to break out the install CDs, my friend asked a very surprising question: "So are you going to install FreeBSD on my system?"
It took a while for the words to sink in. I mean, my friend works in the publishing industry, and while she uses computers all day for word processing and presentations and stuff like that, I didn't expect her to know about FreeBSD. So I asked "Why FreeBSD? Have you been reading OSNews again?"
She gave me a strange look and replied "No, because FreeBSD is free, and I've heard all sorts of things about Linux getting picked up by the big corporates. Those IBM ads are everywhere! I thought Linux was going to be expensive...more expensive than Windows!"
I went ahead and install GNU/Debian for her, lecturing her solidly on the finer points of apt-get while we installed all 6 CD-ROMs from my laptop over a heavily degraded 802.11b link (I'd removed all the RF shielding from her PC's case to 'lap' the hard drive). But it got me thinking. Are Linux distros losing out to FreeBSD when it comes to new users simply because of their names? I mean, who's going to know that GNU/Debian Linux doesn't cost $699 per seat? FreeBSD says immediately that the product is free
I'll put a question to the community...do people think that it might be worth re-naming Debian in some markets (like campus bookstores, for instance) to FreeDebian? I mean, Tux could even hold a pitchfork or something. Do people think that a 'marketing friendly' name is important? Would this get the Debian developers off-side with the FSF, or would they understand? Would the viral nature of the BSD license necessitate distribution changes because of the 'Free' in the name? I welcome comments from the GNU/Linux and FreeBSD communities equally!
Thanks for the suggestions hdparm, but since I posted my original comment my colleagues and I have decided on taking a hardware-oriented approach to solve our problem. Specifically, this will involve careful removal of the outer metal shell of each of the Seagate Cheetah SCSI hard drives from our RAID1+0 setup and making a few changes to the internal structure of the drive to effectively 'overclock' the hard drives. Let me explain
Stock Seagate Cheetahs use a fairly standard aluminium drive shaft, much like the one in a consumer grade piece of rubbish. We are replacing each of these with a carbon propeller shaft and light-weight fly wheel, which will increase initial acceleration of the drive platters, and will allow them to spin at a maximum speed of 17,500rpm versus the standard 10,000rpm. This should see our rate of apt-get transactions improve dramatically. But that's not all. As any good CPU overclocker knows, 'lapping' the contact surface of their heatsink will remove microscopic imperfections and result in a closer contact between heatsink and CPU. We too will be 'lapping' each hard drive platter. Of course this is dangerous to the platters, so we are always sure to use a fresh Kleenex each time. Once the platters are lapped, we can alter the suspension and damping characteristics of the read/write heads, making them float even closer to the platter and resulting in sportier turn-in, less body roll and more predictable handling even when dealing with 'rough' packages such as Troll Tech's Qt libraries which still have an aura of 'non-free' about them.
Finally we short-circuit resistor A24-J, which amazingly unlocks a special 'developers' mode of the hard drive, and firmware commands may be directly inputted using a text editor. We have developed a set of SCSI firmware routines which recognise the apt-get and.deb file formats even at the lowest level of hardware, offering stellar apt-get-goodness. Using a customised version of apt-get implemented in a mix of x86 assembler and Python (for the performance critical parts), apt-get is now able to bypass the Linux kernel, PC BIOS and the SCSI controller card, and communicate with the hard drive mechanics directly. This adds approximately an extra 60% to overall performance, to say nothing of the improvement in overall reliability and robustness.
We feel that these modifications will result in a drive array that will provide a superior platform for high-throughput enterprise level apt-get package management, regardless of filesystem. In fact we have very little choice about filesystem, since the lapping procedure with the Kleenex irreversibly etches tracks and sectors onto the drive surface. No need to worry about 5% of the drive being wasted on superuser-only space after a reformat! Now, I realise that these types of hardware mods may not be in the reach of all Debian users out there. I'm happy to discuss this further with the community if necessary. I am also creating a HOW-TO, which will be distributed via apt-get mirrors in the form of an 'info' document (man pages are filled with inaccuracies due to the inherently lossy compression techniques used in their production. RMS was really onto something with info!!!).
These are some pretty encouraging results. The hard work put in by all the kernel developers has obviously paid off in a big way. However, after reading the article I still have a few questions about kernel 2.6 performance, namely filesystem performance. Rapid random read/write access is obviously highly critical for enterprise type applications, such as apt-get package management and package database updates. Basically with the 2.4.x series of kernels, filesystem performance using either the ext2 or ext3 schemes could drop to below 5 apt-get package installs per second, even on large SMP/RAID systems. I have been investigating the use of raw disk I/O (similar to that used for high performance table spaces in products like Oracle and DB2) to reach my target of 100 apt-get package installations per second on commodity level hardware, via custom kernel level ATA and SCSI chipset drivers. But I'd love to hear that FS speeds have been improved in the 2.6 kernel. Has anybody benchmarked this aspect of the new kernel? And if so, when could we expect to see Debian start shipping with the 2.6 kernel? I look forward to reading the community's response.
The situation described sounds quite similar to one which I found myself in about 5 years ago. My undergraduate and early postgraduate training had been in psychology, mostly concerning leadership and group dynamics in small populations isolated from the norms of everyday society, such as special-ed classes, mental institutions or high-security prisons. Retards. Misfits. The kind of guys who would get their heads flushed down the latrine at high school, and then get shit on for good measure. It was a fascinating area to work in, but getting access to subjects was difficult due to ethical and logistical restraints. That's when I turned to the online open source community, as it provided an essentially limitless supply of subjects fitting perfectly into the population requirements of my study. And that's how I got my start in computers.
At first, I would just lurk in discussion forums, making notes and performing statistical evaluations of the linguistic nuances of every vi versus emacs argument (did you know that the term 'assfucker' is the most commonly used word in these discussions?). I even began experimenting with my own Debian Linux server at home to get a feel for what it was like to be part of the community I was studying. One thing lead to another, and pretty soon I had a small collection of Debian boxes at home, and drawing on my high-school knowledge of LOGO, I quickly taught myself to write a rudimentary web server which delivered web pages to the browser via a LOGO-scripting plugin, with all the HTML page rendering commands faithfully reproduced in LOGO statements. Full CSS support and JavaScript was a hurdle let me tell you, but 520,000 lines of LOGO later and it was complete. But I needed a way to easily deliver my new creation to my users. One of my prime research forums were the Debian support forums. I asked around there for advice. Apt-get was the answer. It struck me like a FreeBSD CD-ROM hurled across a room by an angry OSNews reviewer trying to change the desktop colors in KDE. I quit my PhD that day, and concentrated on improving apt-get. It has been the singular focus of mu life since that day
To get back to the point, I'm now a well respected member of the open source community, and there are plenty of businesses out there using my code. When a company relies on your code, they know you're going to be a good hire. That was how I got my foot in the door in the IT industry. Now the Fortune 500 come to my door. I'm even thinking of adapting apt-get to be the front end for a new jobs database which matches up people fresh into the IT industry from other areas with prospective employers.
This is a really interesting article, and shows just how deeply computers have permeated the crevices of our everyday lives. I was recently in attendance at the Toshiba Developer's Forum in Tokyo, and they gave an extensive 1 hour presentation of the real-time virtual modelling system. Let me tell you, it's damned impressive. I especially liked the part where the virtual dummy was clothed in a promotional bomber jacket from the 1998 JavaWorld convention, and then they were able to use an accelerated aging feature to show how the jacket would look today in 2004, after being subjected to the rigors and weather effects of 5 years of unemployment and living under the Golden Gate bridge that is so typical of a Java developer these days. Simply brilliant!
But that wasn't the most interesting part. Behind the scenes, the software draws upon a vast digital library of clothing images, and it needs to be able to drag them off a centralised clothing server and install them quickly on the computer running the kiosk in the clothes store. Of course managing a digital inventory of several thousand clothing packages and being able to quickly install them on remote machines is a challenge. And it gets harder when you consider the short lifespan of today's fashions: what is current today is an embarrasment tomorrow, and the clothing definition files need to be constantly updated. Fortunately the Toshiba engineers had a very powerful open source resource to draw upon: apt-get!
At Toshiba, they saw that Debian's apt-get package management system was a perfect 'fit' for a digial clothing management system. New fashions could be installed as easily as getting the central controlling software to issue an 'apt-get install boob-tube'. By checking the sources.list file, the kiosk computer is able to download regionalised versions of whatever clothing is being requested...Japanese versions of the same item are sometimes radically different to the Albanian version! Updating to a new look is just as simple. For example, 'apt-get dist upgrade aguilera-crack-whore'. Simple!
You'd be really surprised where apt-get is turning up these days. For so many problems, it fits like a glove! (sorry, couldn't resist!). It's a great day to be an apt-get user! apt-get dressed to kill!
Additional packaging systems for FreeBSD?
on
FreeBSD 5.2 Review
·
· Score: 2, Flamebait
On the other hand, it has limited modern hardware support, small annoyances at places and that not many binary packages are available and so compilations from ports may take long time
I believe that the lack of a large, centralized resource for FreeBSD binary packages is one of the biggest things holding back BSD acceptance in the open source community at the moment. I worked a few months ago as a contract system administrator in a university computer science department, and they were evenly split between FreeBSD and Linux usage for their day-to-day work. However, the Linux users (they were running Debian 2.2 mostly...they were fairly conservative and were waiting for the 'stable' branch to reach 'stable-stable' before upgrading...or even the 'stable-stable-stable' stage where not even the/etc files are able to be edited any more...faculty meetings often sounded like discussions between horse trainers with all the talk of 'stable this', 'stable that'. But I digress.) had a big advantage over the FreeBSD users when it came to installing packages. There was an on-campus apt mirror which I'd set up, and it was a simple matter for the Linux users to issue a quick 'apt-get install' command to grab the latest binaries or Justin Timberlake MP3s without compilation holdups
This brings me to my next question. Instead of going down the hard route which has been suggested on a number of FreeBSD discussion forums and trying to write binary translation layers for BSD/Mac OS X.dmg packages to get access to a rich source of binary software (the PowerPC-x86 translator is only in alpha at the moment and it runs quite slowly, although AltiVec acceleration is on the to-do list), what about bundling apt-get with FreeBSD? That way BSD users could switch from the ports system to the tried and true apt-get when binary packages are desired. Only minimal tweaking would be required if my investigations are correct.
The largest problem then would possibly be one of naming. If FreeBSD was bundled with apt-get as a supplementary package system, would the viral nature of the GPL require that the whole system be named GNU/FreeBSD? Or would an exemption be granted in a case like this?
I look forward to hearing the community's feedback.
I have a loose consultative association with prosecutors trying the antitrust case in France. He feels it's a fairly straightforward case in legal terms, but the real challenge is the remedy phase. I have been persuading him to shoot for a remedy that forces Microsoft to port all of their major products to Linux so that they may easily be installed by a commericial vrsion of apt-get or similar packaging tool. Trusted apt-get has been in development for some time and is the obvious choice for deploying Microsoft products whilst still providing the security and necessary commerical restrictions that Microsoft requires for all of their products.
Expect to hear about Microsoft and this apt-get remedy shortly. Watch this space.
This reminds me of one of my recent consulting contracts in which I was charged with providing a solution for seamlessly monitoring and maintaining a large x86 cluster. since many of the problems encountered on this project would be common to all clustering projects, so maybe this information will be useful to the virginia tech guys (i've just sent off an email to eric raymond, who is in charge of their cluster -- I know eric from previous collaborations, such as fetchmail, others)
Well anyway, when faced with the problem of how of manage this huge cluster of PCs, I first turned to the wealth of superb GNU/Linux and GNU/BSD code available in linux after some unsuccessful starts using fetchmail (damn u eric!), we ended up going with apt-get!
Once I realised that I could model the plethora of hardware suppliers involved in the project as "mirrors", and individual bundles of hardware upgrades as "packages", it all became simple.
Needless to say, the innate flexibility of the apt-get code allowed the entire project to be done well before due date and way under budget. Here's how it worked -
When an essential piece of hardware would be released, say a new video card from nvidia (those cluster guys are mad for farming out bryce5 renders), a central administrator would simply issue a single command -- apt-get dist-cluster upgrade video
Behind the scenes, this would initiate a cascade of value searches on ebay and other quality hardware vendors for the best possible video card around that could be supported by the present hardware, at the same time incorporating value decisions (using fuzzy logic) on whether it was simply easier to upgrade the entire cluster's mobo, or whatever was necessary.
In this manner, whole new braces of functionality could be built into the cluster with similar commands: apt-get dist-cluster install firewire
and bang! dozens of hardware techs would practically melt out of the walls with firewire cards, cables and various multimedia devices, and befre long, our 1000-node computer cluster was a multimedia monster!
Clearly, this model is exactly what virginia tech is looking for, and i fully expect them to take me up on it. If you have a cluster you like to try it on, just open a term and type: apt-get apt-get-cluster-lib
As you can imagine, acting as the sysadmin of such a large collection of compute nodes would be a tough job. Thousands of nodes, each one needing to be up to date with the latest scientific code, data and documentation. Manually rolling out software to the G5 Xserve cluster might take weeks, and require several staff just to cope. I had the honor of having lunch with several key Virginia Tech staff involved in the project just the other day to discuss these issues with them. How did I snag such a presitigious invitation? It turns out the guys down at VTech are long time fans of one of my earlier creations: apt-get-expose
Of course, in the original implementation (which some of the VTech guys had actually ported to Gentoo to replace the emerge system!), I had to rely on ASCII graphics and animations to replicate the Quartz Expose graphics. But, running natively on Mac OS X and G5 hardware, it would be possible to strip out the text Expose animations, and write PowerPC 970 assembler to directly invoke the OpenGL version! That's not all though. Because the load placed on apt-get-expose would be much larger for a cluster the size of Vtech's, I had to code a parallel graphics engine, taking advantage of the AltiVec unit on each G5. This new implementation, coded in tight hand-tuned Python, actually replicates the entire DirectX 9 platform, but using AltiVec calls for enhanced speed. That way I can use the same code base for Mac OS X and Windows XP when win-apt-get is released.
Man you should see them down at VTech now. Those guys are loving being able to manage up to 1024 individual apt-get sessions at once, and with a simple tap of the F9 key, select a package upgrade from anywhere on the network. It's an example of how the new Apple, open source, and the ingenuity of the original apt-get developers can combine to produce something bigger than just a fancy window tiling animation. apt-get show desktop out.
There is a very important point which is glossed over in the article...what type of packaging system will be used in the Zaurus X11 distro? Yes I know that it's based on Gentoo and you can emerge software, but it's not a true package management system, like, say, apt-get.
With so much of the web's infrastructure now running on Linux systems, the question needs to be asked: "How secure is the average Linux distribution". If Linux is to continue its drive into the data center, with solid distributions like Debian and Mandrake at the spearhead, is it time for the Linux kernel to undergo the same type of rigorous, line-by-line security audit that OpenBSD has been built around? What is the opinion of Slashdot users out there who have had to implement a 'front line' Linux box, exposed to the day to day attacks that are part and parcel of an Internet exposed server? Are you wanting more security, or is Linux solid enough? Is OpenBSD really necessary, or is it mostly just hype? And are our current packaging systems robust enough to prevent the kind of trojan episodes which seem to grip the Windows 2000 Server community on an almost weekly basis. Can apt-get take us up to 2010 in secure confidence? I'd love to hear your opinions.
Secure package management to avoid trojans
on
The Future of Security
·
· Score: 4, Funny
The 'experts' in the article seem to think that restricting access to the internet and to software applications would be a good thing for security in the long run. I'm only a humble system administrator, so it isn't for me to decide on high level policy, only to implement it. But where I feel I can comment is on a technical level. Possibly the biggest threat the average user faces today is that of the 'trojan'. No, not the prophylactic device, but the type of insidious security threat that you invite into your virtual home, where it then uncloaks into something altogether nastier. Devising systems to combat the spread of trojans is something which I devote a lot of my spare time to. Linux users think they may be immune to trojans, but that isn't true. 95% of Linux users trust their binary package managers implicitly, yet this is where the biggest hole is. I propose a solution: Trusted apt-get.
Trusted apt-get is a fully secured, digital rights managed version of the popular package management system for Debian. However, Trusted apt-get differs in many ways. In order to avoid the situation of people being tricked into installing trojan-containing.deb files, all Trusted apt-get packages come from secured, trusted servers. Many of these are hosted in former Russian military data centres, and are easily identified by their '.ru' domain names. This is a mark of trust. Secondly, the Trusted apt-get source code has undergone a line-by-line security audit by Theo from OpenBSD. A lot of people believe that Theo isn't all that keen on Linux, but it's mostly been due to the lack of security focus. Trusted apt-get changes that. The final component is a DRM layer in apt-get, which allows for trusted, copyrighted closed source packages to be easily installed on any Debian system. This DRM layer is implemented using standard UNIX crypt() calls, so it's really portable, yet really secure.
We can all look forward to the day when downloading trusted, trojan free software is as simple as issuing a 'trusted-apt-get install gator' command (followed by a reboot. Rebooting flushes insecure code from the processor execution stack, and is the only NSA-approved way to install software safely on a UNIX/Linux system). I believe Trusted apt-get will be available as the standard package manager from Debian 4.0 onwards. Until then, apt-get play it safe.
Here's a question for all those die-hard Dr Who fans out there. Is there a mention in any publications (The Dr. Who Technical Manual, for instance) what software the Dalek's ran? I know at their core they were the shrivelled remains of a Kaled, but all those servo motors, life support systems and weapons had to be running some type of OS. Might it have been Debian? apt-get install davros? Just a thought.
We certainly should all congratulate Penn State on taking a bold step forward in making online music both accessible and legal. Sure, Apple and iTunes have done a lot in this area already, but what makes this service particularly interesting is that it deliberately targets a group of the population disproportionately represented amongst illegal P2P downloaders: college students. It's a step in the right direction.
Technically though, some have claimed that the Penn State initiative is nothing to write home about. Sure, Napster was exciting 3 or 4 years ago, but it's just another P2P app, and one which critics have (quite deservedly, in my opinion) claimed doesn't scale. When you're talking about a university campus, with thousands of users all packed into a small geographic area, all connected to high speed LAN links, scalability is critical. The old Napster architecture wouldn't cope. Fortunately the Penn State administrators saw this problem coming, and sent out a white paper a few months back calling for suggestions and tenders. Given my previous experiences with large organizations rolling out similar file sharing systems, I thought I could help. And what we came up with at Penn State is something really beyond Napster. It's taking it to the next level. It's open source, and it leverages existing file sharing technologies. Yes, it's based on apt-get.
If there's one thing that being a Debian user has shown me, it's that Debian and apt-get are up to the sustained pressure of 24/7 file distribution. Those Debian mirrors take a hammering! Nobody loves to update their distro using apt-get more often than I do (I know, I've checked the update logs at mirror.debian.org). So in a way apt-get was tailor made for this kind of thing. The one thing that was missing though was a Digital Rights Management system, or DRM.
Now some of you out there will argue that just because apt-get is covered under the GPL, that we couldn't alter it with a DRM layer and not give back to the community. Well that's OK, because we re-licensed it under the BSD license which allows that kind of thing. I think re-licensing is mentioned somewhere in the GPL, but it's further than most people read. Our DRM system is pretty secure, because it's based on the same encryption technology that UNIX uses...crypt(). You won't be seeing students be cracking our apt-get DRM enabled system any time soon, let me tell you!
So basically the whole Penn State Napter thing is powered by apt-get behind that great GUI. But it doesn't end there. We've also been approached by some fairly major software vendors who are interested in using our new apt-get-DRM system to roll out an entirely Digitally Rights Managed version of Linux. Apparently it's been a bit of a hold-up for some major corporates, but a locked down, secure, DRM'ed OS was exactly what they needed. I've even suggested this on a few of the Debian mailing lists where I am a regular, and let me tell you the response was enthusiastic! So hopefully we'll see a little more protection of intellectual property in apt-get and Debian in the future.
Just a reminder to folks who might have missed this announcement earlier (it was buried in one of NASA's smaller research group home pages) that high resolution images of all images from the Mars Spirit rover are available through an apt-get interface for those interested. The URL to add to your apt.sources file is aptsource.spirit.downloads.nasa.gov. To grab the latest image updates, just issue this at the command line:
apt-get update nasa-spirit-images
This will download a.deb package containing all new updated images. This.deb also contains an installation script which will conveniently launch xpaint to view the images as a slideshow. Debian (and apt-get) are used pretty heavily throughout NASA, so it's no surprise the Spirit team has pulled off this little apt-get trick!
Hope this helps lighten the load on the NASA web servers a little for those Debian users out there!
Despite their occasional protestations to the contrary, Microsoft is no stranger to the use of open source software in their products. It is a widely known fact that Microsoft has incorporated elements of the BSD TCP/IP stack and networking tools into their own code, and have done so completely legally: the BSD license allows for this type of code 'borrowing' by corporates. However, I believe there is another opportunity for Microsoft to successfully 'borrow' from the open source community to quickly and efficiently deal with this latest need to keep potentially unprofitable Windows 98 desktops supported: apt-get.
As many of you know, apt-get is a superb tool for distributing, versioning and updating software. As frequent users of Slashdot also know, apt-get can have a number of novel uses, ranging from music distribution to control of space probes, but that is beyond the scope of this post. My suggestion is to both Microsoft and the open source community that apt-get be included in a Service Pack for Windows 98, and that apt-get be used to continue to download updates to this venerable, yet unprofitable (for MS) operating system.
Put simply, apt-get is robust, well tested, and perfectly suited for 'hands off' updating of legacy operating systems like Win98 (look at the years of testing it has undergone in the Debian community). Microsoft can turn their attention to more profitable aspects of the business (such as emerging markets as Xbox Live!), and leave the support of apt-get to the open source community, who does a superb job of supporting these things already. It's a win-win situation. MS can still support older Win98 desktops by relying on the power of open source, and the Debian community gets access to a rich new vein of end-user talent, honed by years of experience with the one OS and their reset buttons.
Would any Debian developers care to comment on a possible strategy for approaching Microsoft with this idea? Obviously a proof of concept would be desirable before we start contacting MS reps. Does anyone have Delphi or VB skills?
In a recent consulting gig, I've been tasked with looking after a few offices full of Mac OS X systems at a design company. As many of you would know, Mac OS X is based upon a FreeBSD Unix foundation, so it's capable of being useful to 'hard core' users such as ourselves, as well as presenting a typically user friendly MacOS face to designers and the like.
One thing I really like about Mac OS X is the increasing number of Unix-derived packages that are available through projects such as fink. Fink uses the venerable apt-get system, derived from Debian, to manage the installation, maintenance and upgrading of traditional Unix packages into the MacOS environment. A neat tool, no doubt.
I'm no BSD expert, but I believed that the *BSD systems came with their own packaging system, namely the 'ports' system. But therein lies the question: if Mac OS X is derived from a FreeBSD kernel, why is the premier system for managing open source software packages derived from Debian's apt-get? Would any regular BSD users care to comment? apt-get sure is convenient, but can these 'ports' make things even easier? Should BSD user mount a campaign on Apple's discussion boards to get these 'ports' included with the Developer's Package of the next release of Mac OS X? Apple is quite the innovator in ports after all, being a pioneer of both USB and FireWire. BSD ports could be another feather in their technical cap.
I look forward to the responses of the BSD community. Mac OS X, powered by FreeBSD, is a really rockin' platform!!
The question of users being sued for running Linux has got me thinking. Now that RedHat no longer offers a free desktop version of their product, would it be possible that a Linux-running site could be sued by RedHat for illegally running a 'pirated' copy of Red Hat Advanced Server? Would this be any different to Microsoft calling in the BSA to investigate a site running unlicensed copies of Windows? What if the RedHat site was running a hybrid type of installation, with portions of the distro taken from the unlicensed 'illegally obtained' version of RHAS, but others, such as package management (apt-get, for example), taken from the free GNU/Debian distro? Are there any lawyers out there that would care to comment. Thanks.
Just a reminder to those Debian users in Niue, the mirror.debian.nu apt-get server will be down until further notice. It seems we were prepare for the Slashdot effect, but not a big fucking cyclone effect.
Thank you,
Local Debian Mirror Administrator
Slashdot Mirror
It seems to me that our package managers (used by the majority of Linux users...not everyone compiles from source) are vulnerable to some type of subversion. They are not controlled or vetted by a central authority. There is no 'certificate' which can be attached to them to guarantee their purity. What the Linux community needs, I feel, is a type of central signing authority or cryptographically sealed DRM-compatible package management system. This could eliminate potential threats associated with trojaned Linux packages. Imagine a secure apt-get. Packages would be enveloped in a tough layer of crypt() security. They would be digitally signed by the Debian project manager, or even Ian Murdock for highly critical packages like the kernel. And it would be impossible to accidently load and install a trojan. Apt-get could even be modified to 'phone home' and let the Debian administrators know which packages where the most popular (and make security updating easier!) packages were being installed and to automatically e-mail users with news of package updates and 'special offers' from co-sponsors. I look forward to the community's response!
Often these types of vulnerabilities only affect one platform (and usually Windows), but does anyone know which platforms are affected by this new exploit? Mac OS X and Linux too? Does it make any difference if I used apt-get to install the RealPlayer binary instead of the Real packaged one? I'm in the middle of sealing off RealPlatyer ports on all our organization's firewalls at the moment, but a lot of them are running OpenBSD and we're having trouble keeping them up long enough to edit the firewall config files.
Could anyone comment on the use of assembly in major open source projects? Is there any now? Will its use increase to take advantage of vector units and the like? What about cross-platform assembler? Could we one day see an assembly dialect with the traditional 'raw' access to the machine which hard core developers love, coupled with a Java-like virtual machine for cross platform compatibility? I look forward to the community's response!
I was talking with some of my colleagues in network security this morning about the OpenBSD exploit and means by which future exploits may be avoided. One suggestion which was raised was that the OpenBSD 'ports' system may be to blame. After all, if you need to add packages on a BSD system, 'ports' must be opened, and when ports are open on firewall boxes, bad things happen. Debian's apt-get system for example does not require 'ports' to work properly, and therefore may be immune from this type of exploit. Is this a possible solution? I look forward to hearing the community's responses!
My hope is that the Groklaw project will pay sufficient attention to the GNU/Debian Linux distribution due to its historically important position as a Linux distribution truly dedicated to remaining 'free', and operating within the bounds of a clearly spelled out social contract. These features, as well as the fact that GNU/Debian is maintained not by a corporate entity, but by volunteers, make it worthy of a special mention in the history of Linux. In addition, I would like to see a line-by-line historical commentary on the CVS commit logs for apt-get. That would be great.
Which leads me to my question: Has anyone had any experience with these 'cluster ready' distros? Have they used them for the type of rollout described in the article (ie: chess-playing supercomputer)? What are your opinions on the package management included in the distribution, ie: does it make it easy to load packages onto several hundred nodes in a coordinated fashion? Would a massively distributed version of apt-get be a suitable solution in this problem space? Would it be possible to meta-manage a Beowulf cluster by using a massive distributed/parallel genetic algorithm to autonomously develop a distributed apt-get manager rather than tie up precious Debian developer resources? What could happen if apt-get developed a kind of primitive sentience, backed by a 256-node Beowulf cluster? I look forward to the community's feedback!
It took a while for the words to sink in. I mean, my friend works in the publishing industry, and while she uses computers all day for word processing and presentations and stuff like that, I didn't expect her to know about FreeBSD. So I asked "Why FreeBSD? Have you been reading OSNews again?"
She gave me a strange look and replied "No, because FreeBSD is free, and I've heard all sorts of things about Linux getting picked up by the big corporates. Those IBM ads are everywhere! I thought Linux was going to be expensive...more expensive than Windows!"
I went ahead and install GNU/Debian for her, lecturing her solidly on the finer points of apt-get while we installed all 6 CD-ROMs from my laptop over a heavily degraded 802.11b link (I'd removed all the RF shielding from her PC's case to 'lap' the hard drive). But it got me thinking. Are Linux distros losing out to FreeBSD when it comes to new users simply because of their names? I mean, who's going to know that GNU/Debian Linux doesn't cost $699 per seat? FreeBSD says immediately that the product is free
I'll put a question to the community...do people think that it might be worth re-naming Debian in some markets (like campus bookstores, for instance) to FreeDebian? I mean, Tux could even hold a pitchfork or something. Do people think that a 'marketing friendly' name is important? Would this get the Debian developers off-side with the FSF, or would they understand? Would the viral nature of the BSD license necessitate distribution changes because of the 'Free' in the name? I welcome comments from the GNU/Linux and FreeBSD communities equally!
Stock Seagate Cheetahs use a fairly standard aluminium drive shaft, much like the one in a consumer grade piece of rubbish. We are replacing each of these with a carbon propeller shaft and light-weight fly wheel, which will increase initial acceleration of the drive platters, and will allow them to spin at a maximum speed of 17,500rpm versus the standard 10,000rpm. This should see our rate of apt-get transactions improve dramatically. But that's not all. As any good CPU overclocker knows, 'lapping' the contact surface of their heatsink will remove microscopic imperfections and result in a closer contact between heatsink and CPU. We too will be 'lapping' each hard drive platter. Of course this is dangerous to the platters, so we are always sure to use a fresh Kleenex each time. Once the platters are lapped, we can alter the suspension and damping characteristics of the read/write heads, making them float even closer to the platter and resulting in sportier turn-in, less body roll and more predictable handling even when dealing with 'rough' packages such as Troll Tech's Qt libraries which still have an aura of 'non-free' about them.
Finally we short-circuit resistor A24-J, which amazingly unlocks a special 'developers' mode of the hard drive, and firmware commands may be directly inputted using a text editor. We have developed a set of SCSI firmware routines which recognise the apt-get and .deb file formats even at the lowest level of hardware, offering stellar apt-get-goodness. Using a customised version of apt-get implemented in a mix of x86 assembler and Python (for the performance critical parts), apt-get is now able to bypass the Linux kernel, PC BIOS and the SCSI controller card, and communicate with the hard drive mechanics directly. This adds approximately an extra 60% to overall performance, to say nothing of the improvement in overall reliability and robustness.
We feel that these modifications will result in a drive array that will provide a superior platform for high-throughput enterprise level apt-get package management, regardless of filesystem. In fact we have very little choice about filesystem, since the lapping procedure with the Kleenex irreversibly etches tracks and sectors onto the drive surface. No need to worry about 5% of the drive being wasted on superuser-only space after a reformat! Now, I realise that these types of hardware mods may not be in the reach of all Debian users out there. I'm happy to discuss this further with the community if necessary. I am also creating a HOW-TO, which will be distributed via apt-get mirrors in the form of an 'info' document (man pages are filled with inaccuracies due to the inherently lossy compression techniques used in their production. RMS was really onto something with info!!!).
I look forward to the GNU/community's feedback.
These are some pretty encouraging results. The hard work put in by all the kernel developers has obviously paid off in a big way. However, after reading the article I still have a few questions about kernel 2.6 performance, namely filesystem performance. Rapid random read/write access is obviously highly critical for enterprise type applications, such as apt-get package management and package database updates. Basically with the 2.4.x series of kernels, filesystem performance using either the ext2 or ext3 schemes could drop to below 5 apt-get package installs per second, even on large SMP/RAID systems. I have been investigating the use of raw disk I/O (similar to that used for high performance table spaces in products like Oracle and DB2) to reach my target of 100 apt-get package installations per second on commodity level hardware, via custom kernel level ATA and SCSI chipset drivers. But I'd love to hear that FS speeds have been improved in the 2.6 kernel. Has anybody benchmarked this aspect of the new kernel? And if so, when could we expect to see Debian start shipping with the 2.6 kernel? I look forward to reading the community's response.
At first, I would just lurk in discussion forums, making notes and performing statistical evaluations of the linguistic nuances of every vi versus emacs argument (did you know that the term 'assfucker' is the most commonly used word in these discussions?). I even began experimenting with my own Debian Linux server at home to get a feel for what it was like to be part of the community I was studying. One thing lead to another, and pretty soon I had a small collection of Debian boxes at home, and drawing on my high-school knowledge of LOGO, I quickly taught myself to write a rudimentary web server which delivered web pages to the browser via a LOGO-scripting plugin, with all the HTML page rendering commands faithfully reproduced in LOGO statements. Full CSS support and JavaScript was a hurdle let me tell you, but 520,000 lines of LOGO later and it was complete. But I needed a way to easily deliver my new creation to my users. One of my prime research forums were the Debian support forums. I asked around there for advice. Apt-get was the answer. It struck me like a FreeBSD CD-ROM hurled across a room by an angry OSNews reviewer trying to change the desktop colors in KDE. I quit my PhD that day, and concentrated on improving apt-get. It has been the singular focus of mu life since that day
To get back to the point, I'm now a well respected member of the open source community, and there are plenty of businesses out there using my code. When a company relies on your code, they know you're going to be a good hire. That was how I got my foot in the door in the IT industry. Now the Fortune 500 come to my door. I'm even thinking of adapting apt-get to be the front end for a new jobs database which matches up people fresh into the IT industry from other areas with prospective employers.
apt-get install you-too-can-be-a-crossover-success-in-IT!!!
But that wasn't the most interesting part. Behind the scenes, the software draws upon a vast digital library of clothing images, and it needs to be able to drag them off a centralised clothing server and install them quickly on the computer running the kiosk in the clothes store. Of course managing a digital inventory of several thousand clothing packages and being able to quickly install them on remote machines is a challenge. And it gets harder when you consider the short lifespan of today's fashions: what is current today is an embarrasment tomorrow, and the clothing definition files need to be constantly updated. Fortunately the Toshiba engineers had a very powerful open source resource to draw upon: apt-get!
At Toshiba, they saw that Debian's apt-get package management system was a perfect 'fit' for a digial clothing management system. New fashions could be installed as easily as getting the central controlling software to issue an 'apt-get install boob-tube'. By checking the sources.list file, the kiosk computer is able to download regionalised versions of whatever clothing is being requested...Japanese versions of the same item are sometimes radically different to the Albanian version! Updating to a new look is just as simple. For example, 'apt-get dist upgrade aguilera-crack-whore'. Simple!
You'd be really surprised where apt-get is turning up these days. For so many problems, it fits like a glove! (sorry, couldn't resist!). It's a great day to be an apt-get user! apt-get dressed to kill!
I believe that the lack of a large, centralized resource for FreeBSD binary packages is one of the biggest things holding back BSD acceptance in the open source community at the moment. I worked a few months ago as a contract system administrator in a university computer science department, and they were evenly split between FreeBSD and Linux usage for their day-to-day work. However, the Linux users (they were running Debian 2.2 mostly...they were fairly conservative and were waiting for the 'stable' branch to reach 'stable-stable' before upgrading...or even the 'stable-stable-stable' stage where not even the /etc files are able to be edited any more...faculty meetings often sounded like discussions between horse trainers with all the talk of 'stable this', 'stable that'. But I digress.) had a big advantage over the FreeBSD users when it came to installing packages. There was an on-campus apt mirror which I'd set up, and it was a simple matter for the Linux users to issue a quick 'apt-get install' command to grab the latest binaries or Justin Timberlake MP3s without compilation holdups
This brings me to my next question. Instead of going down the hard route which has been suggested on a number of FreeBSD discussion forums and trying to write binary translation layers for BSD/Mac OS X .dmg packages to get access to a rich source of binary software (the PowerPC-x86 translator is only in alpha at the moment and it runs quite slowly, although AltiVec acceleration is on the to-do list), what about bundling apt-get with FreeBSD? That way BSD users could switch from the ports system to the tried and true apt-get when binary packages are desired. Only minimal tweaking would be required if my investigations are correct.
The largest problem then would possibly be one of naming. If FreeBSD was bundled with apt-get as a supplementary package system, would the viral nature of the GPL require that the whole system be named GNU/FreeBSD? Or would an exemption be granted in a case like this?
I look forward to hearing the community's feedback.
I have a loose consultative association with prosecutors trying the antitrust case in France. He feels it's a fairly straightforward case in legal terms, but the real challenge is the remedy phase. I have been persuading him to shoot for a remedy that forces Microsoft to port all of their major products to Linux so that they may easily be installed by a commericial vrsion of apt-get or similar packaging tool. Trusted apt-get has been in development for some time and is the obvious choice for deploying Microsoft products whilst still providing the security and necessary commerical restrictions that Microsoft requires for all of their products.
Expect to hear about Microsoft and this apt-get remedy shortly. Watch this space.
This reminds me of one of my recent consulting contracts in which I was charged with providing a solution for seamlessly monitoring and maintaining a large x86 cluster. since many of the problems encountered on this project would be common to all clustering projects, so maybe this information will be useful to the virginia tech guys (i've just sent off an email to eric raymond, who is in charge of their cluster -- I know eric from previous collaborations, such as fetchmail, others)
Well anyway, when faced with the problem of how of manage this huge cluster of PCs, I first turned to the wealth of superb GNU/Linux and GNU/BSD code available in linux after some unsuccessful starts using fetchmail (damn u eric!), we ended up going with apt-get!
Once I realised that I could model the plethora of hardware suppliers involved in the project as "mirrors", and individual bundles of hardware upgrades as "packages", it all became simple.
Needless to say, the innate flexibility of the apt-get code allowed the entire project to be done well before due date and way under budget. Here's how it worked -
When an essential piece of hardware would be released, say a new video card from nvidia (those cluster guys are mad for farming out bryce5 renders), a central administrator would simply issue a single command --
apt-get dist-cluster upgrade video
Behind the scenes, this would initiate a cascade of value searches on ebay and other quality hardware vendors for the best possible video card around that could be supported by the present hardware, at the same time incorporating value decisions (using fuzzy logic) on whether it was simply easier to upgrade the entire cluster's mobo, or whatever was necessary.
In this manner, whole new braces of functionality could be built into the cluster with similar commands:
apt-get dist-cluster install firewire
and bang! dozens of hardware techs would practically melt out of the walls with firewire cards, cables and various multimedia devices, and befre long, our 1000-node computer cluster was a multimedia monster!
Clearly, this model is exactly what virginia tech is looking for, and i fully expect them to take me up on it. If you have a cluster you like to try it on, just open a term and type: apt-get apt-get-cluster-lib
too easy!
Of course, in the original implementation (which some of the VTech guys had actually ported to Gentoo to replace the emerge system!), I had to rely on ASCII graphics and animations to replicate the Quartz Expose graphics. But, running natively on Mac OS X and G5 hardware, it would be possible to strip out the text Expose animations, and write PowerPC 970 assembler to directly invoke the OpenGL version! That's not all though. Because the load placed on apt-get-expose would be much larger for a cluster the size of Vtech's, I had to code a parallel graphics engine, taking advantage of the AltiVec unit on each G5. This new implementation, coded in tight hand-tuned Python, actually replicates the entire DirectX 9 platform, but using AltiVec calls for enhanced speed. That way I can use the same code base for Mac OS X and Windows XP when win-apt-get is released.
Man you should see them down at VTech now. Those guys are loving being able to manage up to 1024 individual apt-get sessions at once, and with a simple tap of the F9 key, select a package upgrade from anywhere on the network. It's an example of how the new Apple, open source, and the ingenuity of the original apt-get developers can combine to produce something bigger than just a fancy window tiling animation. apt-get show desktop out.
emerge apt-get!
With so much of the web's infrastructure now running on Linux systems, the question needs to be asked: "How secure is the average Linux distribution". If Linux is to continue its drive into the data center, with solid distributions like Debian and Mandrake at the spearhead, is it time for the Linux kernel to undergo the same type of rigorous, line-by-line security audit that OpenBSD has been built around? What is the opinion of Slashdot users out there who have had to implement a 'front line' Linux box, exposed to the day to day attacks that are part and parcel of an Internet exposed server? Are you wanting more security, or is Linux solid enough? Is OpenBSD really necessary, or is it mostly just hype? And are our current packaging systems robust enough to prevent the kind of trojan episodes which seem to grip the Windows 2000 Server community on an almost weekly basis. Can apt-get take us up to 2010 in secure confidence? I'd love to hear your opinions.
Trusted apt-get is a fully secured, digital rights managed version of the popular package management system for Debian. However, Trusted apt-get differs in many ways. In order to avoid the situation of people being tricked into installing trojan-containing .deb files, all Trusted apt-get packages come from secured, trusted servers. Many of these are hosted in former Russian military data centres, and are easily identified by their '.ru' domain names. This is a mark of trust. Secondly, the Trusted apt-get source code has undergone a line-by-line security audit by Theo from OpenBSD. A lot of people believe that Theo isn't all that keen on Linux, but it's mostly been due to the lack of security focus. Trusted apt-get changes that. The final component is a DRM layer in apt-get, which allows for trusted, copyrighted closed source packages to be easily installed on any Debian system. This DRM layer is implemented using standard UNIX crypt() calls, so it's really portable, yet really secure.
We can all look forward to the day when downloading trusted, trojan free software is as simple as issuing a 'trusted-apt-get install gator' command (followed by a reboot. Rebooting flushes insecure code from the processor execution stack, and is the only NSA-approved way to install software safely on a UNIX/Linux system). I believe Trusted apt-get will be available as the standard package manager from Debian 4.0 onwards. Until then, apt-get play it safe.
Here's a question for all those die-hard Dr Who fans out there. Is there a mention in any publications (The Dr. Who Technical Manual, for instance) what software the Dalek's ran? I know at their core they were the shrivelled remains of a Kaled, but all those servo motors, life support systems and weapons had to be running some type of OS. Might it have been Debian? apt-get install davros? Just a thought.
Technically though, some have claimed that the Penn State initiative is nothing to write home about. Sure, Napster was exciting 3 or 4 years ago, but it's just another P2P app, and one which critics have (quite deservedly, in my opinion) claimed doesn't scale. When you're talking about a university campus, with thousands of users all packed into a small geographic area, all connected to high speed LAN links, scalability is critical. The old Napster architecture wouldn't cope. Fortunately the Penn State administrators saw this problem coming, and sent out a white paper a few months back calling for suggestions and tenders. Given my previous experiences with large organizations rolling out similar file sharing systems, I thought I could help. And what we came up with at Penn State is something really beyond Napster. It's taking it to the next level. It's open source, and it leverages existing file sharing technologies. Yes, it's based on apt-get.
If there's one thing that being a Debian user has shown me, it's that Debian and apt-get are up to the sustained pressure of 24/7 file distribution. Those Debian mirrors take a hammering! Nobody loves to update their distro using apt-get more often than I do (I know, I've checked the update logs at mirror.debian.org). So in a way apt-get was tailor made for this kind of thing. The one thing that was missing though was a Digital Rights Management system, or DRM.
Now some of you out there will argue that just because apt-get is covered under the GPL, that we couldn't alter it with a DRM layer and not give back to the community. Well that's OK, because we re-licensed it under the BSD license which allows that kind of thing. I think re-licensing is mentioned somewhere in the GPL, but it's further than most people read. Our DRM system is pretty secure, because it's based on the same encryption technology that UNIX uses...crypt(). You won't be seeing students be cracking our apt-get DRM enabled system any time soon, let me tell you!
So basically the whole Penn State Napter thing is powered by apt-get behind that great GUI. But it doesn't end there. We've also been approached by some fairly major software vendors who are interested in using our new apt-get-DRM system to roll out an entirely Digitally Rights Managed version of Linux. Apparently it's been a bit of a hold-up for some major corporates, but a locked down, secure, DRM'ed OS was exactly what they needed. I've even suggested this on a few of the Debian mailing lists where I am a regular, and let me tell you the response was enthusiastic! So hopefully we'll see a little more protection of intellectual property in apt-get and Debian in the future.
Happy (safe) downloading, Penn State students!
apt-get update nasa-spirit-images
This will download a .deb package containing all new updated images. This .deb also contains an installation script which will conveniently launch xpaint to view the images as a slideshow. Debian (and apt-get) are used pretty heavily throughout NASA, so it's no surprise the Spirit team has pulled off this little apt-get trick!
Hope this helps lighten the load on the NASA web servers a little for those Debian users out there!
As many of you know, apt-get is a superb tool for distributing, versioning and updating software. As frequent users of Slashdot also know, apt-get can have a number of novel uses, ranging from music distribution to control of space probes, but that is beyond the scope of this post. My suggestion is to both Microsoft and the open source community that apt-get be included in a Service Pack for Windows 98, and that apt-get be used to continue to download updates to this venerable, yet unprofitable (for MS) operating system.
Put simply, apt-get is robust, well tested, and perfectly suited for 'hands off' updating of legacy operating systems like Win98 (look at the years of testing it has undergone in the Debian community). Microsoft can turn their attention to more profitable aspects of the business (such as emerging markets as Xbox Live!), and leave the support of apt-get to the open source community, who does a superb job of supporting these things already. It's a win-win situation. MS can still support older Win98 desktops by relying on the power of open source, and the Debian community gets access to a rich new vein of end-user talent, honed by years of experience with the one OS and their reset buttons.
Would any Debian developers care to comment on a possible strategy for approaching Microsoft with this idea? Obviously a proof of concept would be desirable before we start contacting MS reps. Does anyone have Delphi or VB skills?
One thing I really like about Mac OS X is the increasing number of Unix-derived packages that are available through projects such as fink. Fink uses the venerable apt-get system, derived from Debian, to manage the installation, maintenance and upgrading of traditional Unix packages into the MacOS environment. A neat tool, no doubt.
I'm no BSD expert, but I believed that the *BSD systems came with their own packaging system, namely the 'ports' system. But therein lies the question: if Mac OS X is derived from a FreeBSD kernel, why is the premier system for managing open source software packages derived from Debian's apt-get? Would any regular BSD users care to comment? apt-get sure is convenient, but can these 'ports' make things even easier? Should BSD user mount a campaign on Apple's discussion boards to get these 'ports' included with the Developer's Package of the next release of Mac OS X? Apple is quite the innovator in ports after all, being a pioneer of both USB and FireWire. BSD ports could be another feather in their technical cap.
I look forward to the responses of the BSD community. Mac OS X, powered by FreeBSD, is a really rockin' platform!!
The question of users being sued for running Linux has got me thinking. Now that RedHat no longer offers a free desktop version of their product, would it be possible that a Linux-running site could be sued by RedHat for illegally running a 'pirated' copy of Red Hat Advanced Server? Would this be any different to Microsoft calling in the BSA to investigate a site running unlicensed copies of Windows? What if the RedHat site was running a hybrid type of installation, with portions of the distro taken from the unlicensed 'illegally obtained' version of RHAS, but others, such as package management (apt-get, for example), taken from the free GNU/Debian distro? Are there any lawyers out there that would care to comment. Thanks.
Just a reminder to those Debian users in Niue, the mirror.debian.nu apt-get server will be down until further notice. It seems we were prepare for the Slashdot effect, but not a big fucking cyclone effect. Thank you, Local Debian Mirror Administrator