Slashdot Mirror
Extensive Coverage of Ottawa Linux Symposium 2006
cdlu writes "LWN and NewsForge both extensively covered the goings-on at this year's OLS. NewsForge: day 1, day 2, day 3, and day 4. LWN (subscription required for most): article 1, article 2, article 3, and article 4." I especially enjoyed the description of reverse engineering a USB device from cdlu's coverage of day 3; one day wireless USB devices will really work with out-of-the-box Linux! Update: 07/25 04:57 GMT by T : Eric Preston, who delivered that talk on reverse engineering USB devices, kindly linked to both his slides and the accompanying screenshots.
How long can this event be held in canada? I mean, sure its the right environment for penguins now but what about global warming?
-
I can think of a hundred different places I'd rather go for a symposium before Ottawa.
Obviously, they must have not be expecting a lot of out-of-towners.
The best presentations, IMHO:
Killing Kittens (David Arlie)
LuserSpace sucks (DaveJ)
Myths about Linux (Greg KH)
OK, not the exact names, but you get the picture.
The first one adresses graphic vendors that think their closed driver has fairy poo on them.
The second adresses brain dead programmers that keep mistreating files AND the general OS.
The third has the coolest last slide I've seen in a presentation.
how long until
Almost 1,000 pages of very interesting whitepapers from the event can be found in the first and second PDFs.
I read the papers and listen to radio here in Ottawa. I run Linux on my machine and have helped my girlfriend and her little daughter switch as well, we're the sort who'd like to have known that this was going on. But not a peep.
Was there advertising in 'trade' papers that I just didn't see? Or is this basically a convention for out-of-towners with no seats for 'off the street' folks? More of a 'Linux Symposium' (held in Ottawa) than an 'Ottawa Linux Symposium' I'd say... heh.
Kevin
How long until we have one of these in the Cincinnati area? Nothing ever happens here except shootings.
DIS
Getting a driver into Linux is so full of road hazards because the "community"(read: the loudest mouths) is too idealistic, eccentric, and inflexible...and as a result, most companies go "fuck that 2% of the market" and release Windows drivers that, long as they work, nobody complains about, ever. Even MacOS X is easier; it's a much more stable "target" hardware/software-wise, and the community doesn't mix politics with purchases.
Not to mention most likely Brand X wireless card came complete with drivers from OEM company Z, just with Brand X silkscreened on the PCB...and Brand X couldn't "release" the drivers or write open-source ones if they wanted to.
Please help metamoderate.
That's a pity that a few talks about containers (OS-level virtualization, a la advanced Jails, a la Solaris Zones/Partitions) were not covered at all. There were (at least) four of them:
- Eric Biederman's talk about namespaces
- Cedric Le Goater's talk about application mobility (a.k.a. live migration of containers)
- A BOF on containers, moderated by Dave Hansen
- A BOF on the resource management (one of the components of containers), moderated by Dipkanar Sarma
There was also a half-an-hour discussion about containers on the Kernel Summit. Let me summarise all these in a few lines:
1. Containers are a real alternative (or a good addition) to Xen and paravirtualization. In most cases they can be used for same applications, without incurring all the Xen's overhead and dirty hacks)
2. Everybody wants containers in the mainstream kernel
3. There are different implementations (IBM's stuff, OpenVZ, Linux-VServer, and Eric's) and their developers need to agree upon them what to submit/push into mainline. This is hard to do, but a required step.
4. Resource management: User Beancounters from OpenVZ is a good (the only?) candidate for inclusion into mainstream.
-- Kir Kolyshkin, OpenVZ project leader.
Has the Wireless USB (WUSB) specification even been finalized yet? Isn't it a little early to get excited about a niche protocol that may never reach the market?
Or does the submitter not understand the difference between Wireless USB and USB Wireless Networking Adapters?
"Corbet says that there's not a firm kernel bug count. As the number of users increases, he noted, so to does the number of bug reports. More code means more bugs, even if the proportion of bugs (bugs per thousand lines of code) drops."
Oh dear. I can see that being quoted.
I reserve the write to mangle english.
(Ottawa)(Linux)(Symposium) (2006) Hhhm.. something tells me no booth babes were present..
//WR
Well I met a babe, so I never made it to a booth.
Undetectable Steganography? Yep, there's an app fo
1999
And, boy oh boy, its anything but penquin weather here. We get the extremes and its on the hot end of the scale right now.
You know, I used to think just like this -- though I didn't consider it 'whining', I worried about the practice, thinking it might just put the vendors off.
And then I watched the OpenBSD project flame the hell out of a Hifn representative for asserting that his company provided 'open documentation' (when in fact acquiring said documentation required registration that the OpenBSD developers felt violated their privacy). When I first read the systematically harsh response to the Hifn representative (including Theo's threat to drop the free driver from the OpenBSD tree), I was absolutely stunned that a group of free software developers would be so reckless.
But it got me thinking... we can't all bend over and ask for it from the vendors forever. Linux marketshare is growing in every segment, and we do have an increasing amount of support from giants like IBM. If it were possible for the projects to take a unified stance (across Linux and the three *BSDs) and persistently demand programming specifications from the vendors, what's going to happen -- they're going to say "fuck you for asking" and drop their binary drivers too?
Something tells me that giving your customers the finger, even if it's only an operating system or two only represent 6-10% of your desktop market, isn't the sort of thing you do to appease shareholders. So while they might not respond immediately, it's not like we're losing anything.
I'm thinking we should start a unified petition to AMD now that they're acquiring ATI - form an online petition to AMD that says "We are NVIDIA customers who will eBay our GPUs tomorrow and buy ATI if you release open drivers".
There is a mall attached to the convention center. Go to the food court. Proceed to the Japanese place. Eat.
Warning: do not forget to smuggle real Mountain Dew into the country. Canada banned caffeine in drinks that are not brown, and Pepsi chose color over content.
Nobody wants vendors to release drivers. We don't want them, and we never will want them. Simply supply the docs they already have, and let us make drivers. We will support their hardware for them, for free, and it will always be up to date, always work out of the box, and always be consistant with other similar hardware for users. Quit re-hashing the same stupid excuses that have nothing to do with reality.
I wonder if there will be any protesters shouting "BSD, BSD, DOWN WITH LINUX, BSD, INTEGRATION, BSD, SECURITY, BSD, CODE QUALITY, BSD, TRULY FREE CODE, BSD, BSD, DOWN WITH GNU, BSD, DOWN WITH RECURSIVE ACRONYMS, BSD, BSD, WINE IS AN EMULATOR, BSD, BSD".
Or if someone insults someone else's text editor. "WHAT DID YOU SAY ABOUT vim? I DON'T NEED AN ENTIRE OS FOR A TEXT EDITOR! OR A BROKEN PINKY!" "HEY YOU, WIMPY VIIMACS USERS, ed PWNS YOU ALL. IF YOU NEED MORE THAN A "?" FOR OUTPUT, YOU ARE TEH SUCK""EMACS CAN RUN vim AND ed FOOLS!" Then someone will break out a beowulf cluster of Linux flame-throwers.
Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.
It hurts the same way that multitask operating systems hurt - there is definitely some overhead for task switching. Really, single task OSs gives more CPU to the task and thus are more efficient.
In multiuser operating systems there are a lot of checks for uids, gids etc.
Now the question - do we want multiuser and multitask OSs? Do we want ownership and permission checks on files? Do we want resourse limits (such as ulimit, disk quotas)?
Same answer applies to containers.
-- Kir Kolyshkin, OpenVZ project leader.
I recently bought a Huawei CDMA card. It worked 'out of the box' with Ubuntu. The USB version also worked first time.
Of course, we had to figure out the wvdial config file to make it do anything, but that didn't take long.
Max.
one day wireless USB devices will really work with out-of-the-box Linux!
Yeah right. That will happen the day after video card manufacturers release Free Software drivers...
Don't blame me, I didn't vote for either of them!
No, sorry, same answer does NOT apply to containers.
Ordinary users of all types definitely get real benefits from multitasking.
Ordinary business users, and to a lesser extent home users (because of malware and accidents), benefit from access controls and resource limits.
Containers are rarely of use and never important. If I'm isolating something for development, I'll at least use VMWare. That lets me do multiple kernel versions. For serious testing, I'll just buy extra hardware. If it is security I want and I don't trust myself to configure SE Linux right, the same applies: VMWare or hardware. You're going to have massive security holes if you think you can have multiple root users running around.
For all this pain, for all the bugs and performance loss caused to MILLIONS of ordinary machines, regular users get NOTHING.
I get that you are trying to sell something. Well, that's fine and quite understandable, but please don't fuck up my kernel to do it.
No, I am not trying to sell something -- OpenVZ is free software (free as in freedom). By the way, OpenVZ developers fixed a lot of bugs in mainstream, so they are rather fixing your kernel than fucking it up. All of the OpenVZ code is #ifdef'd so if no appropriate options are selected the code is not compiled in. Finally, you do not understand what containers are useable for...hmm I can try and give you some examples if you like. Basically, the same isolation/security that you'd rather use VMware for -- the only thing is with containers you do not have to pay performance penalty. Also, containers are hardware-independent, they can be managed "en masse" (unlike VMware VMs), they can be live migrated from box to box. And in case you do not want to run different kernels -- containers are much better/efficient to use than full VMs. Speaking of multiple root users on the box -- each and every HSP sells those cheap VPSs based on one of the existing implementation of containers. They sell it as cheap as $10/month or so -- and the root access is included. So go buy one and try to crack the system. I mean, please do not spread the "it's totally insecure" FUD if you do not have any real experience with that.
-- Kir Kolyshkin, OpenVZ project leader.
Linux Weekly News' articles are only available to subscribers the first week they come out. After that they are available to all. Kudos to the editor, Jon Corbet, for finding a solution that enables the content that he creates (and that of other contributers) to be available to all. Albiet after a slight delay. :)
Restore America: Dr. Ron Paul for President!
For development isolation, multiple kernels is a requirement. I need to run Fedora Core 6 test 1, RHEL 4, Gentoo's latest, SuSE 9, SuSE 10.1, Slackware 10...
Often, it goes beyond that. Multiple OSes may be a requirement. You don't do Windows XP or OpenBSD.
As far as I can tell, the HSP/VSP stuff is the only real use of containers. That is very obscure. It's not nice to severely hack up the kernel for something so obscure.
BTW, you are wrong about VMWare. It lets you migrate live images. (not the free version)
As for security: yes I do have experience. I can't talk about it in detail. The general idea though: you have a lot of complexity, you're trying to plug every last hole including information leaks... not going to happen. By it's nature, VMWare is more secure. The main vulnerabilities are the serious risk of compromise via the interface used by vmtools (example: buffer overflow in the cut-and-paste support) and the normal problem of info leaks on shared hardware. Containers are far worse. You have the whole damn kernel to secure, in a way that is not normally required. We've had enough trouble keeping root secure from users, never mind from other "root" users.
Well, you can run different distros in different containers on the same system (yep, the kernel will be the same and in most cases it is not a problem). Really, I do not have problem running all the distros you mentioned (we haven't tried FC6 yet though...but I do not foresee any major problem here).
Speaking of security - all those HSP would went out of business very soon if VPSs they sell would be hackable. Also - if you have any knowledge about yet unclosed holes - security@kernel.org is a better place for it than doing a FUD on slashdot.
Speaking of containers usage -- it is not just for HSPs, it is mostly for the server consolidation. And in this scenario one usually does not need to mix different OSs on a singe box, just because one has 100+ of linux boxes and 100+ of other OS boxes -- so one consolidates those to, say, 40 linux boxes and 50 other os boxes.
Also note the maintainability of vmware vs. Containers. If you use vmware for consolidation -- you end up with the same number of servers to manage. In case of containers you can manage (i.e. apply a software update) all of them in parallel, it is not needed to login to each system.
Also note the dynamic resourse mgmt in containers. You can not increase the RAM amount for a VM while it is running - but it's a trivial thing to do for a container. Resizing a disk image online is also a problem with VMs - but just a matter of changing per-container disk quota.
I can continue this comparison, but the general idea is - if you do not require multiple kernels, using containers is much more efficient and (!) natural. And if you do want multiple kernels - you can actually mix two approaches, i.e. run containers inside a VM, and have the best of both worlds.
-- Kir Kolyshkin, OpenVZ project leader.
There are many buyers for undisclosed holes. Probably you'd be amazed at the pay. I don't think security@kernel.org will pay very much. Anyway...
If you need to patch many VMWare images in parallel, you just do it. People manage server farms all the time, certainly not involving login on any of them. (You think Google has some dude doing that? Server 765430, server 765431, server 765432, done! Whew! Time to start the next update!) Really, there are tools for this.
You can increase the RAM on a physical machine while Linux is running. I'm serious. (proper motherboard required, obviously) So there really isn't any reason why VMWare couldn't let this happen. Trying to decrease memory is more difficult, but that's rarely a desired operation anyway. Linux can sometimes do it.
The same goes with disk, except that you don't need VMWare to support it if you use iSCSI or NBD. I've done it on physical hardware. If VMWare doesn't already support this, the fix is easy.
reverse-engineer and replace kqemu and the nvidia driver and i *will* stop using them. the problem is the sub-par drivers that no one works on, not that the binary drivers are being used. (and don't you dare tell me to work on them. i have neither the time nor the experience to write a video card driver.)
grey wolf
LET FORTRAN DIE!
O.K., this looks like an ethical question, and looks like my ethical principles is a bit different of yours. Anyway...
-- Kir Kolyshkin, OpenVZ project leader.