On Tue, 2010-12-21 at 16:43 -0800, Andres Salomon wrote:
Given that OLPC machines out there currently have broken battery
information with UPower and friends, I think that the patches should be
applied.
Doing stuff in the EC or device-tree may be done in the future, but
even after it's
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+
On Fri, 2010-12-10 at 16:38 -0800, Andres Salomon wrote:
It there is, it's not at all clear. The values are fetched from the
EC, which get them from the EEPROM.
If the EC knows them, can't we ask the EC rather than pulling numbers
our of our arse in the kernel?
The DT has a battery entry,
). Whereas what shows up in the XO Neighborhood View (and
in 'olpc-xos') appears to ignore standards-compliance.
Surely all your machines can communicate quite happily using IPv6
link-local addresses? Why this fascination with Legacy IP?
--
David WoodhouseOpen Source
NOT looking forward to the day when my refrigerator has its
own IPv6 address, and reports to third parties how much beer I have
downed.
Nothing prevents it from doing that with Legacy IP either :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
port to which nothing is connected saves no power,
right? I don't see the appeal.
It was nice that we could stagger the switching on of USB ports, to
avoid crashes due to power surges and resulting drops on the power rail.
How sure are you that we won't need similar workarounds in CL1B?
--
David
give a raw
mtd0 instead.)
No, that's only for mount.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Devel mailing list
Devel@lists.laptop.org
http
could sensibly look at moving the actual TX handling
back into the TX routines. Carefully.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Devel mailing list
harder. When something goes wrong inside the
device's internal firmware, there really isn't much you can do about it
at all.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
get some of your cycles; I'm
just saying that the answer doesn't seem obvious and straightforward.)
Now I work for Intel, I hear occasional vague rumours that you found
something wrong, but you never actually seem to _tell_ me so...
--
David WoodhouseOpen Source
Probably better to use the official designation.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
---
(Carried in git://git.infradead.org/~dwmw2/random-2.6.git)
drivers/mmc/host/sdhci-pci.c |2 +-
include/linux/pci_ids.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
---
(Carried in git://git.infradead.org/~dwmw2/random-2.6.git)
drivers/mtd/nand/cafe_nand.c |6 +-
include/linux/pci_ids.h |1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers
Also, stop looking at the NAND controller (0x4100) and checking the
device class. For a while during development, all three functions on the
chip had the same ID. We made them fix that fairly promptly, and we can
forget about it now.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
---
(Carried
On Mon, 2008-07-21 at 09:51 -0700, Deepak Saxena wrote:
On Jul 21 2008, at 13:39, C. Scott Ananian was caught saying:
2) JFFS2's behavior when the file system is almost full. When it gets
almost full, it can spend all its time trying to garbage collect, and
you can lose completely (the
On Mon, 2008-07-21 at 10:29 -0700, Deepak Saxena wrote:
I can go ahead and apply the existing Nokia patch into the 8.2 kernel as
a short-term measure but don't want to arbitrarilly choose a reservation
size.
Dave, do you have a suggestion as to what percentage should be reserved to
keep
On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote:
The userspace tool is extremely awkward to use (since it requires the
driver modules to be unloaded which in turn makes the identification
of devices on the XO even more difficult)
I believe there's a way for libusb to unbind the
On Tue, 2008-06-03 at 10:12 -0400, Dan Williams wrote:
So why are we doing this with the driver, and not the userspace update
tool? Marvell keeps wanting to do firmware update in the driver, and we
(David and I at least) keep saying no. If there are issues that prevent
the userspace firmware
On Tue, 2008-06-03 at 11:34 -0300, Ricardo Carrano wrote:
A necessary rectification:
Firmware updates from the driver are the only method that works
currently. If we want to name one method a disaster, we would have
to choose the userspace tool, since it will brick many of your active
On Tue, 2008-06-03 at 11:44 -0300, Ricardo Carrano wrote:
Please check comment on:
http://wiki.laptop.org/go/Active_Antenna_Reprogramming#User_Space_Method
Where am I looking? The 'has failed twice' claim? That's hardly a decent
bug report. Put a coherent report in trac, and we'll look at it.
On Tue, 2008-06-03 at 11:03 -0400, John Watlington wrote:
My bad. This is now Trac #7170
http://dev.laptop.org/ticket/7170
All of the information in this ticket comes from email exchanged with
dcbw and dwmw2 when I first discovered it.
Didn't we fix that months ago by increasing the
On Tue, 2008-06-03 at 12:13 -0400, C. Scott Ananian wrote:
2008/6/3 Bill Mccormick [EMAIL PROTECTED]:
A couple of my XOs are reporting what look like FS error messages on boot:
[91.463670] JFFS2 notice: (664) check_node_data: wrong data CRC in data
node at 0x1ec215f0: read 0x3e7c7e03,
On Tue, 2008-06-03 at 11:28 -0400, Dan Williams wrote:
I'm happy to test this out and try to
get the userspace tool working again if given:
Last time I knew, the userspace tool _was_ working.
Although we'd stripped out the support from the kernel driver ages ago
and wrote libertas-flash.py,
is great.
Acked-By: David Woodhouse [EMAIL PROTECTED]
--
dwmw2
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
On Mon, 2008-05-19 at 07:01 -0400, Dan Williams wrote:
Is the firmware multicast address limit the same for every firmware from
5.0.x up to 9? Is it something that people with the firmware dev kit
can change with a recompile? Because if it changes between any of the
firmware revisions
On Sun, 2008-05-18 at 20:48 +0100, David Woodhouse wrote:
Try it like this... completely untested and hence probably broken in
some stupid and minor way, but testing is something for tomorrow, not
Sunday night when I'm supposed to be cooking dinner.
This version seems to work, and as an added
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
On an SMP host, are you sure we can't end up setting the multicast list
simultaneously on the two logical devices?
(A: No.)
Try it like this... completely untested and hence probably broken in
some stupid and minor way, but testing
On Thu, 2008-05-15 at 11:01 -0700, Brian Cavagnolo wrote:
This patch is based on a patch from Shailendra Govardhan. It introduces
several new iwprivs: {get,set}_bootflag {get,set}_boottime {get,set}_def_chan
{get,set}_def_protid {get,set}_def_metid {get,set}_def_meshcap
{get,set}_def_meshid.
On Tue, 2008-05-13 at 16:15 -0700, Andrew Morton wrote:
On Tue, 13 May 2008 19:12:27 -0400 Andres Salomon [EMAIL PROTECTED] wrote:
And FWIW, I like the 80 char limit _except_ when it comes to strings.
I don't normally bother about the strings, unless it is obvious that
the surrounding
On Tue, 2008-05-13 at 15:06 -0700, Andrew Morton wrote:
On Tue, 13 May 2008 22:59:26 +0100
David Woodhouse [EMAIL PROTECTED] wrote:
On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote:
On Tue, 13 May 2008 13:20:19 -0400
Andres Salomon [EMAIL PROTECTED] wrote:
On Tue, 13 May
On Tue, 2008-05-13 at 19:12 -0400, Andres Salomon wrote:
Can we come to a consensus for the sake of outside contributors?
Rather than telling the cozybit folks one thing, and having checkpatch.pl
and CodingStyle claim another (Dave, surely you wouldn't argue against
using checkpatch?), can we
On Wed, 2008-05-14 at 02:17 -0700, Andrew Morton wrote:
On Wed, 14 May 2008 09:44:12 +0100 David Woodhouse [EMAIL PROTECTED] wrote:
I'm sorry if that offends you, but making code more readable helps me
find real bugs, and that is more important to me than the 80-column
rule.
Code which
On Mon, 2008-05-12 at 23:49 -0400, John Watlington wrote:
On May 12, 2008, at 8:46 PM, Marcus Leech wrote:
A few questions:
What driver is required on an ordinary Linux system for the active
antennae?
[I ask because plugging one in to a hot-off-the-presses F9 system
causes said
Shukla and David Woodhouse.
Signed-off-by: Javier Cardona [EMAIL PROTECTED]
Tested by: Ricardo Carrano [EMAIL PROTECTED]
Looks good, but please don't introduce any more of the 'u8' and 'u32'
nonsense. If types are user-visible, we have to use the '__u32' form. If
not, we might as well use
On Tue, 2008-05-13 at 13:47 +0100, David Woodhouse wrote:
On Fri, 2008-05-09 at 21:00 -0700, [EMAIL PROTECTED] wrote:
Each device maintains its own list of bound multicast addresses. Those
lists
are merged and purged from duplicate addresses before being sent to
firmware.
The maximum
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
And even without that, it doesn't seem to do the right thing. Set
IFF_PROMISC mode on one interface, then on the other, then clear it on
the first it should remain set in hardware. And AFAICT it doesn't.
I'll see if I can make
On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote:
On Tue, 13 May 2008 13:20:19 -0400
Andres Salomon [EMAIL PROTECTED] wrote:
On Tue, 13 May 2008 15:45:39 +0100
David Woodhouse [EMAIL PROTECTED] wrote:
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
And even
On Fri, 2008-05-09 at 16:06 -0700, Javier Cardona wrote:
Hi,
We are happy to announce the first development release of the wireless
firmware + driver compatible with the kernel's mac80211 stack. This is
a first step towards supporting a soft Access Point (hostap) on the
xo, a project in
On Thu, 2008-05-08 at 10:06 +1200, Martin Langhoff wrote:
Dennis, David,
There is right now something that I am having trouble understanding
how it's done - related to kernel packaging. Is there any
documentation on how the RH team manages kernels with additional
patches?
All I can find
On Thu, 2008-04-17 at 17:09 -0400, Michael Stone wrote:
Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows:
Currently firmware 5.110.22.p8/9 does not support more than 8 multicast
mac addresses. Is there a possibility that any given point of time there
are more than 8
On Fri, 2008-04-18 at 10:58 -0400, Ricardo Carrano wrote:
Mmm, if the driver says it is 32 and the firmware only allows for 8,
we have a problem, don't we? ;-)
Indeed. Do we know which versions of firmware support which numbers of
addresses? Remember, this driver handles lots of devices, some
On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote:
Is it possible to associate shared activities with ethernet ports
instead of whole multicast addresses? Then we would only need one single
multicast address and do the filtering on the ethernet ports (eg IP is
port
On Fri, 2008-04-18 at 11:50 -0400, Polychronis Ypodimatopoulos wrote:
what's possible? why not?
David Woodhouse wrote:
On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote:
Is it possible to associate shared activities with ethernet ports
instead of whole multicast
On Fri, 2008-04-18 at 12:08 -0400, Polychronis Ypodimatopoulos wrote:
Dynamic mapping from a single 6-byte address to multiple 16-byte
addresses?
The other way round. Given an IPv6 multicast address, there exists a MAC
address associated with that IPv6 address. When we join the multicast
On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote:
You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on
_all_ ethernet frames. IP has nothing to do with this. Instead of
looking at the first 6 bytes (destination mac) for a specific multicast
address,
On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote:
You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on
_all_ ethernet frames. IP has nothing to do with this. Instead of
looking at the first 6 bytes (destination mac) for a specific multicast
address,
On Fri, 2008-04-18 at 14:19 -0400, Ricardo Carrano wrote:
The multicast filter was implemented in 22p8 (with the limit of 8 since
them). Is that what you're asking?
Then the firmware was just ignoring the MAC list before then, and always
implementing the ALLMULTI behaviour?
--
dwmw2
On Wed, 2008-03-05 at 20:09 -0300, Ricardo Carrano wrote:
It may be possible that NetworkManager is triggering the scannings
(any other possibility?). Anyway, why 4 scan commands and how this
becomes 2 probe requests? Any ideas?
We send multiple scan commands to the firmware for each scan
On Mon, 2008-02-25 at 15:02 -0500, Ricardo Carrano wrote:
14:43:34 Err file about_dlg.c: line 250 (splash_update): assertion
failed: (ul_sofar = ul_count)
Aborted (core dumped)
We shouldn't be hacking epan/dissectors/register.c directly -- it's
autogenerated. If we'd regenerated it
On Mon, 2008-02-25 at 04:37 -0500, John Watlington wrote:
http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.patch
Has this been submitted to the wireshark developers? I took a quick look
through it and removed some whitespace noise, and spotted a change in
add_fixed_field() behaviour in the
On Thu, 2008-02-14 at 17:56 -0200, Ricardo Carrano wrote:
If you don't turn many XOs on at the same time, you won't have salut
preventing gabble to work.
My fear is that we are complicating things unnecessarily.
But we _do_ turn on many XOs at the same time. Hell, we've seen one
teacher
On Fri, 2008-01-18 at 10:08 -0500, Dan Williams wrote:
Yes. The active antennas firmware would need to be slightly altered to
start on firmware boot, but the normal XO firmware should certainly be
radio-off-until-driver-enabled (by setting IFF_UP or device open).
Let us make a clear
On Fri, 2008-01-18 at 16:56 -0500, John Watlington wrote:
Michail,
This would be 3107, right ?
3109 is when we started seeing the auto-update mode.
OK, so can we go between 3109 and 3107 in both directions using
libertas-flash.py or did the protocol get changed without telling us?
We
On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote:
Ideally, we want to just kill the auto-mesh-repeater mode, where boot2
times out after 5 seconds and loads the firmware from the internal flash
(which is obviously larger on these devices than on the XO). Can we
achieve that just
On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote:
What is the post-boot firmware flash functionality supposed to apply to,
the host-less active antenna? (which is what I heretofore had
understood).
As Ben says, they're the same thing. If you don't load the firmware
within 5 seconds of the
On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote:
There is an iwpriv eth0 radiooff/radioon IOCTL hook in the firmware
which was meant to control the radio power directly - it was removed a few
months ago since it wasn't considered to its thing in the proper linux
manner.
I looked
Stuck in tin cans again, I've been looking at building an OLPC kernel
based on 2.6.24, starting by going through the diffs between our stable
tree and 2.6.22 (on which it's based).
Ideally, we should be committing almost nothing directly to our tree --
it should _all_ be going upstream. As much
On Mon, 2008-01-14 at 06:48 -0700, Jonathan Corbet wrote:
Actually, I've sent all of my changes into the mainline; I *believe*
that things need to go the other way. There were some things I put in
which ran afoul of a freeze on the OLPC side.
Sounds good to me; I'll just drop any cafe_ccic
On Sun, 2008-01-13 at 02:30 -0500, Albert Cahalan wrote:
David Woodhouse writes:
http://www.csr.com/products/unifirange.htm
They claim that that is a 1-chip solution. Is it really?
I have no reason to believe otherwise -- why do you ask?
Some people make some fairly preposterous claims
http://www.csr.com/products/unifirange.htm
--
dwmw2
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
On Tue, 2008-01-08 at 19:34 -0700, Rob Savoye wrote:
Sigh, I am getting so tired of this issue with codecs... Gnash for
the XO is built without support for any proprietary audio or video
codecs. Because of the patent laws, the OLPC project (which is based in
the US) cannot
On Tue, 2008-01-08 at 20:06 -0700, Rob Savoye wrote:
To go along with this, I've been working on a clone of the Adobe
Media Server, so we can steam free codecs. Right now you can only do
this with icecast, but it doesn't speak the flash protocols, which
Gnash now supports.
Oooh. Gnash
On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote:
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST). Furthermore,
On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote:
Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this
problem. It's easy to discover the shortest way out of the mesh
(nearest mesh portal), but setting up the larger mesh networkl
infrastucture means you also need to
On Wed, 2008-01-09 at 14:43 -0500, Michail Bletsas wrote:
What do you propose to do about it? Throw away pointless engineering
into cobbling together some way of making Legacy IP work a bit better? I
seriously hope not. Just switch off the Legacy IP, as we should have
done months ago, and
On Mon, 2008-01-07 at 18:15 +0100, NoiseEHC wrote:
This message is primarily written for Bernardo Innocenti but everybody
with relevant knowledge is welcomed to give some insight.
I have decided two months ago that will write an asm implementation for
zlib inflate (decompression) since
On Sun, 2008-01-06 at 01:45 -0500, Michael Stone wrote:
On Sun, Jan 06, 2008 at 12:37:33AM -0500, Build Announcer Script wrote:
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1514/
+kernel.i586 0:2.6.22-20071213.7.olpc.807beb7d0b8a49a
-kernel.i586
On Thu, 2008-01-03 at 22:09 -0800, Dan Krejsa wrote:
Attached are the output from 'iwlist scan' and dmesg. 'quibble' is the
router I'm trying to connect to. It's a netgear WPN824v2.
After collecting these logs, and making another unsuccessful attempt to
connect to quibble (i.e. clicking on
On Thu, 2008-01-03 at 10:05 -0800, Dan Krejsa wrote:
I (perhaps foolishly) updated to joyride-1496, and after rebooting my
G1G1 XO cannot connect to my wireless router.
After a while, the neigborhood view becomes completely blank.
From a terminal, what happens when you run 'iwlist scan'? Can
On Mon, 2007-12-31 at 18:10 +, David Woodhouse wrote:
An interesting goal would be cleaning up CONFIG_OLPC so that
it could be enabled in stock kernels of standard Linux distros.
I actually see that as a prerequisite for getting the thing upstream.
And the first step along that path
On Sun, 2007-12-30 at 12:05 -1000, Mitch Bradley wrote:
I meant the OLPC kernel.
I presume that OLPC changes will be offered to mainline in some batch
fashion, rather than piecemeal. This particular one is of no upstream
value in isolation, as it is utterly dependent on OLPC-specific EC
On Mon, 2007-12-31 at 12:56 -0500, Bernardo Innocenti wrote:
btw, we still have code in /etc/init.d/olpc-configure that
tries to use one of those private ioctls to remap the leds,
and outputs errors if they're missing. Is this still needed?
Yes, I think so. And I think it probably even
On Fri, 2007-12-21 at 09:04 +, David Woodhouse wrote:
Thanks for the feedback. Unfortunately it didn't reach the people it
needs to, because for some reason you dropped them from Cc. Please could
you check what caused your mailer to misbehave, and remedy that?
Btw, it also broke threading
Thanks for the feedback, Adam.
--
dwmw2
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
On Fri, 2007-12-14 at 09:54 +0200, Artem Bityutskiy wrote:
UBI/UBIFS is too large and difficult to implement their support in XO
boot-loader. So I plan to use the following scheme:
1. Have 2 MTD partitions - mtd0 and mtd1. mtd0 is small (say, 10MiB), and has
JFFS2 FS. It contains /boot,
On Fri, 2007-10-12 at 12:30 -1000, Mitch Bradley wrote:
This sounds a lot like a problem that I was working on yesterday.
(for reference: https://dev.laptop.org/ticket/4184 )
Can you go on IRC (freenode, #olpc) ? If so, I would like to work with
you to see if my latest firmware works around
On Tue, 2007-09-25 at 08:07 -0400, Bernardo Innocenti wrote:
The fact that the XO has an x86 CPU makes porting OSes and
applications easier,
That might be true for non-portable operating systems which are bound to
x86, but I dispute that it's true for any well-written application.
--
dwmw2
On Thu, 2007-09-13 at 06:12 -0400, Bernardo Innocenti wrote:
There was an alternative libertas driver which uses the device in 'dumb'
mode with the kernel's mac80211 stack. Coupled with mesh support in
mac80211 that might make a somewhat suboptimal alternative to truly free
firmware.
On Tue, 2007-09-11 at 18:54 -0400, Eduardo Silva wrote:
who knows how can I get the battery capacity in the latest builds, ex:
4000mAh
I don't believe we're given this information from the EC. Perhaps we
could manage to work it out though -- Richard?
--
dwmw2
On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote:
This interrupt scheduled for 233-40ms is what sounds wrong. It should
just continue to blaze off the EHCI resume path.
... after 20ms have passed, not almost 200.
Ah, right. Sorry, I missed the order of magnitude discrepancy. Are
On Mon, 2007-09-03 at 09:27 +0100, David Woodhouse wrote:
On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote:
This interrupt scheduled for 233-40ms is what sounds wrong. It should
just continue to blaze off the EHCI resume path.
... after 20ms have passed, not almost 200.
Ah
On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote:
Note: ohci_pci_resume does msleep 20.
Hm. It's just waiting for the hardware to settle, right? Do the resume
functions for the devices themselves actually have to wait until this is
complete, before they can do anything?
It really
On Wed, 2007-08-29 at 08:31 -0400, Marcelo Tosatti wrote:
What you think is the easier/proper way to postpone this console work
to happen after the resume process is finished?
It's spending all its time waiting for characters to be sent out a
serial port which isn't even going to have anything
On Fri, 2007-07-13 at 11:00 -0700, Greg KH wrote:
Isn't there a concern that the on-board security firmware in XO would
constitute tivoization essentially of the same sort that GPLv3 aims to
block?
Which is one reason the Linux kernel developers do not agree with that
part of the GPLv3
On Tue, 2007-07-03 at 18:14 +0100, Richard Hughes wrote:
http://people.freedesktop.org/~hughsient/fedora/7/i386/
Upload the PowerPC version too please; I'd like to test it with the new
PMU battery driver too.
--
dwmw2
___
Devel mailing list
On Wed, 2007-06-27 at 18:37 -0400, Ivan Krstić wrote:
On Jun 27, 2007, at 2:57 AM, David Woodhouse wrote:
Nevertheless, it's an accurate description of what happened.
Let's agree to disagree.
Sounds like a fine plan.
As long as we're united on the common goal to drop vserver as soon
On Tue, 2007-06-26 at 20:45 -0400, Ivan Krstić wrote:
On Jun 26, 2007, at 7:23 PM, David Woodhouse wrote:
because the people working on the security stuff
let it all slide for too long and now have declared that we don't have
time to do anything sensible.
That's a cutely surreal take
On Tue, 2007-06-26 at 15:59 -0400, Mike C. Fletcher wrote:
* VServer only appeared in public discussions yesterday or so
AFAIK, yet it's apparently already the chosen path for doing the
system compartmentalization.
It's a short-term hack, because the people working on the
On Wed, 2007-06-20 at 16:52 -0400, Ivan Krstić wrote:
This is a complete non-sequitur. Remember the bloody mess that was
PSN?
I remember a lot of noise and pointless paranoia, but no actual _mess_.
But I don't own a tinfoil hat -- so maybe someone's controlling my brain
to make me not see the
88 matches
Mail list logo
