Domain: onshore.com
Stories and comments across the archive that link to onshore.com.
Comments · 5
-
It ought not have been a girl, that Linux Girly
-
Check out Raul Silva's GNU/Linux Posters
-
The company I work for wires buildings...I work for a company called onShore. We have wired several buildings in Chicago with ethernet, a server, and a T1 (sometimes multiple). Video on demand is in the near future. We also offer file server services, etc. Unfortunately, there is nothing "techie" about it. The buildings are all high priced, high rise apartments. Nothing a self respecting techie would live in.
:-P The customers are usually your average user.Its really no big deal. There is no immediate advantage to this service other than being able to use a standard ethernet card and not having to purchase a cable modem or DSL router. As a techie, I would be running my own servers and would have no use for the server in the building. And I can't imagine liking my neighbors enough to make use of the 100 Mbit building-wide LAN. The chances of any of my friends living in the same building as me are pretty slim. Although I think the posibilities for video on demand are intriguing...
-matthew
-
my quickiesi think that guy that invented the extra life is crazy. a quote:
I learned early on to channel energies using an aluminum foil dish strapped to my forehead. I have long since ceased to be mortal.
best mousepad: the one with boobs
best pic from the cruise: big iron
best art from the gnu/art site: l33t debian button.. gotta get one
enjoy!
-
Rationale for pushing back the freezeAnyone who's been watching Debian for more than 1 year knows that freeze time is a huge strain on the project. The release manager, Richard Braakman, has stated his wish that the complete duration of the freeze should be no greater than 3 or four weeks.
My discussion with him regarding the preparedness of the boot-floppies, in particular, is just to make sure he has all the information he needs to make this wish into a reality. The whole point is to go into the freeze with a feature-complete and beta-ready installation system; with that in place, a 4 week freeze is plausible. Without it, it's not. For those who remember the slink freeze, that was about a 16 week cycle (it froze in mid-Nov, release in mid-March), and was quite stressful to all. Our goals is that freeze is predicated on a pretty stable set of packages, which makes our own ability to test installation from scratch and slink to potato upgrading in a more sane fashion.
Let me just cover a few other points, quickly.
- The main reason why I want more time for boot-floppies features to go in is that I feel these features are very important. Let me mention them briefly: a new task/profile selection mechanism, with the means to continue to use these mechanisms even after installation; use of apt in almost all cases; an apt configurator, with the capability to autosense official cdroms in expected locations; ability to install base2_2.tgz via http and maybe ftp; bootp/dhcp network data population when available; X package installation hand-holder, able to autosense your correct X server package. I feel these advances are important. Even with the delay, I hope we have time to implement them.
- Those who say we'll never freeze are just talking crazy. We have a lot of desire to update and obsolete the slink distribution.
- Regarding Linux 2.4, no, we do not plan release cycles around Linux release cycles, which should be clear to anyone. For better or worse. Assuming Linux 2.4 is stable (2.2 wasn't that great w.r.t. stability when it came out, IMHO) and comes out in the next couple of weeks, I wouldn't rule out 2.4 for sure. Right now, we're planning on using 2.2.13 (although that can very for our 5 different architectures).
- We do realize that the current release engineering mechanisms are showing the strain of how large the project has grown. There are two approaches to this problem: (a) do more "point releases" of the stable system, which simply requires a larger team than we currently have worrying about stable even after it's released; (b) radically reengineer release management, where the most likely candidate for this is the "package pool" proposal -- I don't have the URL offhand.
- Even with all that being said, I'd like to reiterate that, AFAIK, Debian is the only distribution with a proven and robust way to upgrade your distribution (whether it's for new releases, picking packages out of unstable, or whatever).
- While we're in the "excuses" department, I don't think there are many out there that realize how much effort it is to coordinate Debian in general (or boot-floppies, for that matter). This work goes on behind the scenes, and some of you interpret the slow-moving nature of these issues to indifference. I can assure you we are not indifferent, especially to the criticisms regaring frequency of release and the quality of the boot-floppies.
I'd like to thank all of you who have expressed support and tolerance for Debian here.
.....Adam Di Carlo....adam@onShore.com.....http://www.onShore.c om/