Here is a list of some things that I think would be good for the hardware
library, if you have something that matches which you don't need then please
bring it to a LUV meeting to donate it. Also just bring random stuff that's
small and light.
DDR2 and DDR3 RAM - I think there is plenty of older RAM in the library
Laptop RAM. Not many people want it but those who do want it badly. It also
works in lots of modern printers.
USB Flash storage. While most of us get enough freebies from trade shows I'm
sure that some people need more. It's small and light so I don't mind
carrying them around.
64bit PCs. I'm not planning to carry spare machines to regular meetings, but
I'm happy to store a few in case someone needs one and bring them to a meeting
on demand. Post to the list first if you plan to bring a PC to the meeting.
ATI PCIe video cards. NVidia has driver issues (either a lack of features or
non-free depending on which driver you choose).
Small Ethernet switches that are quiet. Even a 10baseT switch is very handy
if it's small and light.
Micro-USB cables suitable for connecting Android devices (and many other
things) to PCs.
USB power supply as used for phones and tablets.
Android devices. Even devices that run Android 2.1 can be useful if they
aren't broken. More recent Android devices can be useful even if they are a
bit broken (EG a cracked screen still leaves an Android device as a portable
computer with a camera).
Accessories for phones (please clearly label which phone they belong to).
There are multiple standards for things like external microphones for phones,
some old phones are unreasonably expensive to buy parts for. Batteries are
useful if they can take at least 50% original charge, please wrap batteries in
plastic to avoid the risk of short-circuiting.
Here are some things that I personally need:
A US style extension cable that goes from a PC PSU to a monitor. It's not a
very important thing for me but would be nice to have. As few PCs have the
socket for such a cable nowadays there should be a few unused out there.
A quad-core PC with 4*DDR2 sockets that can take full height PCIe cards.
SATA disks with many bad sectors. The ideal would be to have about 0.1% of
reads fail. I'm doing some research into error recovery. Please clearly
write "BAD" on such disks to avoid unfortunate mistakes. Note that when I am
finished experimenting with such disks I will use a hammer to make them
unreadable - just in case the disk problems made it impossible to delete some
of your data.
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Does anyone have real-world experience of using linux's interface
bonding on public networks?
(In the bandwidth-aggregation mode, not the redundancy mode)
I was wondering how I could make the following setup work:
* Rent a VPS in Melbourne with four IP addresses
* Get four (or just two) ADSL connections wired up to home
* Have your VPS connect four VPN connections from itself back to each
of your home IPs.
* Bond all four interfaces together
* Create a fifth VPN connection, this time going over the
bonded-virtual-interface between VPS and home, and then configure your
home server to use that link as the default route?
It sounds pretty messy and I'm not sure it'd actually work in
practice; the routing tables would be hell to get right.
Are there any guides already out there?
From: "James Harper" <james.harper(a)bendigoit.com.au>
>> I posted last year about a problem I was having with Linux's PPPoE
>> functionality in regards to a specific modem. At the time I put it
>> down to a dodgy modem and moved on, but now I've hit it on another
>> modem, and twice seems more than coincidence.
> You aren't a Telstra customer are you?
As said, I had similar issues - and it is an Optus network.
For the case mentioned here, I would go with the commentary on the
ITT: The evidence posted just indicates there's a fucked up router
somewhere in Telstra (or along the path) that's screwing with large
packets, nothing here proves Telstra monitoring.
Why it only affects some hosts? Because routing isn't the same for all
Dave Hellewell <dave.hellewell(a)gmail.com> said,
>> Power supply is next easiest thing to test if you can find a spare.
>> Do the input voltages seem okay? Even if they do it's possible it
>> could still be the power supply.
>My sensors output is pretty wacky (haven't gotten around to a proper
>config), but the BIOS reports numbers that look OK. I have another PSU
>here and I'll give that a spin as a last resort before submitting to the
Neither the bios or any software voltage monitoring are any good in
diagnosing PSU problems as neither reads voltage continiously. For the same
reason most digital voltmeters are no good.
What can happen (I have had it twice) is the PSU voltages can spike down
very quickly and cause the system untold problems. Such a spike will NOT be
picked up by most voltmeters. I have successfully used analog meters to
check this though (An AVO).
All voltages need to be checked including the 12 Volt line. In both my
cases the system lockups were caused by the 12V line droping low (11.2
volts) for only around half a second, causing the hardisks to shutdown.
This caused an unrecoverable error from the kernel.
The symptoms in my case was an almost complete hardlock up but with the
mouse pointer still working.
CPL stock a cheap PCI-Express dual UTP gigabit ether card:
Anyone tried using them in OpenBSD?
Can anyone advise
what manufacturer/model id's it reports, or
any dmesg diagnostic?
(I currently have some Intel Pro/1000 MT cards, but one has
decided to intermittently fail 1GB sync)
Has anyone had any experience with 10GigE?
I'm not after anything at all complex, just a single server that needs
something a little faster than GigE talking to a single switch that can spread
the bandwidth over 12+ GigE ports.
As an aside, I think it would be nice if someone developed an Ethernet card
and switch as one combined device. It would be a PCIe card that looks to the
system like a regular Ethernet port connected to a 4 port switch with the only
software visible difference being that it had 4* the bandwidth of a regular
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
-------- Original Message --------
Subject: [Linux-aus] OSDC 2014 (Gold Coast QLD) Call for Papers now open!
Date: Sat, 31 May 2014 10:32:28 +1000
From: Arjen Lentz <arjen(a)lentz.com.au>
To: linux-aus <linux-aus(a)linux.org.au>
We're looking for presenters to talk at the upcoming Open Source
Developers' Conference (4-7 November 2014, Griffith University Gold
Coast Campus, QLD). Register on the http://2014.osdc.com.au/ site, and
propose a presentation. You can submit as many proposals as you wish,
and come back to edit them later, so why not get started today?
We have space for sessions, tutorials, hands-on workshops with keyboard
or soldering iron (or both!) and yes, Miniconfs.
Speakers attend the conference for free; travel and accommodation is
still your own gig, although we may be able to make arrangements in some
Initial CfP period closes midnight Friday July 4th, but you only have to
get your abstract in at this stage, after that you've got quite a bit of
time to prep your talk or workshop!
While OSDC will be host to a wide range of presentation topics, from
running an open source business or community, to more technical
presentations, the overall conference theme for 2014 is
Open: Open Source software, hardware, data and standards (protocols)
enable higher quality, more secure products, and faster innovation.
Inclusive: Openness enables and encourages exploration, the foundation
of education. Making products accessible to for instance vision impaired
people becomes easier. Affordable products are available to those with
less money. Women, kids, and many other groups can get involved more
easily. These are all opportunities, we must still work to make them happen!
Connected: The last 18 months has seen a tremendous rise in the
development of connected hardware, the connected home, wearables and
sensor equipped devices.
Remember, we have ample space for sessions, tutorials, hands-on
workshops with keyboard or soldering iron (or both!) and Miniconfs.
Go on, put in your cool ideas today! http://2014.osdc.com.au/
(on behalf of the OSDC 2014 organising committee)
linux-aus mailing list
I am about to make some hardware upgrades to my Linux box, and one of the
possibilities is to add an SSD drive for /, /boot, and possibly also swap.
Anyone have any advice on potential issues with the above?
From: "Terry Duell" <tduell(a)iinet.net.au>
> On Thu, 29 May 2014 16:02:33 +1000, Paul Miller <paul.miller(a)rmit.edu.au>
>> I think that using an ssd for swap is a bit of an issue due to the
>> number of likely writes.
> That thought had crossed my mind, but I really don't know enough about it.
> Currently swap isn't used very often, probably less if I install more
> memory, so maybe swap can stay on normal drive.
I have my netbook running with Ubuntu on a SSD drive for a year or so,
without problems so far.
The swap gets used occasionally, the netbook has 2GB only and I am running
a X11 desktop (usually Windowmaker) on it.
On 26 May 2014 19:24, James Harper <james(a)ejbdigital.com.au> wrote:
>> On 26 May 2014 18:07, Russell Coker <russell(a)coker.com.au> wrote:
>> > On Mon, 26 May 2014 17:47:06 Toby Corkindale wrote:
>> >> I don't understand why you're worried about enabling the jumbo frames
>> >> though. It doesn't break backwards compatibility. Your 100baseT stuff
>> >> will continue to function fine.
>> > Except that a switch will drop a jumbo packet destined for a non-jumbo
>> > So you can have situations where things work at low speed but break as
>> soon as
>> > you send lots of data and get a larger TCP segment size.
>> I've never seen that in practice, and I've been running gigabit
>> networks for a while.
>> Rather than totally dropping the packet if the destination port
>> doesn't support it, the switch should alert the sender that they must
>> fragment their packets. Path MTU discovery. Although actually I think
>> some (most?) switches instead just do the fragmentation themselves.
> This almost certainly isn't possible unless it's an L3 managed switch, and even then I've never heard of such a thing. IP is Layer 3 while Ethernet is Layer 2, which is all most switches do.
Ah OK. I stand corrected.
There's definitely some mechanism that lets a jumbo-frame client talk
to a non-jumbo-frame client via a switch though. I swear I do this and
it Just Works(tm).
Perhaps MSS at the IP layer then?