I would like to just jump in here and say that we should generally ease up on bashing Asus in this regard. Remember that Linux advocacy should try to be Pro-Linux and not Anti-MS.

It is noteworthy that Asus has kicked off a computing revolution with the Eee and the help of Linux. The fact that Linux was instrumental in this was not lost on the other comers to the market like e.g HP, who sold out their Linux versions of 2133 in the US - and currently has it on backorder (this reported on the latest Linux Action Show Podcast).

Asus has been an amazingly Linux-friendly company. This is especially brave in a hardware market where the mainstream kowtow's to Redmond.

I'm not so sure about that. I think Asus is more of "an accidental helper", than an actual friend (ie. they use linux because... well they have their commercial reasons ;)) If they really cared so much about opensource (or specifically Linux), they would not have bowed down to whoever wrote up that marketing copy.

That's number 1. Number 2 is them using a wireless chip for which there is no open documentation. Sure, we have the drivers - but what we have for that is primarily as a result of hard work reverse engineering. Bad.

Let us not now snatch defeat from the jaws of victory by bashing a valuable ally :).

Disclaimer: I have no afiliation with Asus whatsoever. The above opinions are my own, and obviously do not reflect official Asus policy.

Cheers
Stephan

-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not help."
-- Andrew Fear, Software Product Manager, NVIDIA Corporationhttp://kerneltrap.org/node/7228

Remote theft of ATM PINs exposes security flaw: blame it on Windoze?

...."Hackers are targeting the ATM system's infrastructure, which is
increasingly built on Microsoft's Windows operating system and allows
remote diagnosis and repair of machines over the Internet."...

Production Operations Engineers - Linden Lab

Hi Everyone,
Linden Lab is currently looking for Production Operations Engineers to
be based in Singapore. The Production Operations team is responsible
for ensuring that the Second Life Grid, the world's largest
collaborative real-time development environment, is stable,
maintainable, and fully operational.
We're looking for people who can rapidly pinpoint and diagnose network
failures, deployment issues, and performance bottlenecks, who can also
create tools which will improve grid stability, as well as communicate
effectively with both techies and non-techies alike. Linden Lab
Operations is a Debian Linux shop. We rely extensively on OSS, and our
in-house systems are usually written in Python or PHP. Our team is
made up of folks who have been involved in large-scale grid management
and site operations for years.
If you have substantial *nix experience and script-fu, familiarity in
managing large system installations, and no fear of complex, dynamic
systems, then you may be who we're looking for.
To apply: http://lindenlab.hrmdirect.com/employment/view.php?req=22085
For more information:
* http://www.lindenlab.com
* http://www.secondlife.com
* http://www.secondlifegrid.net
Regards,
Johan Gozali
_______________________________________________
Slugnet mailing list
Slugnet@...http://wiki.lugs.org.sg/LugsMailingListFaqhttp://www.lugs.org.sg/mailman/listinfo/slugnet

Hello,
Chris Henry wrote:
> Weird wth! Don't they encrypt PINs? No, shouldn't they?
> Is this article saying the sysadmin of that system
> has *legitimate* access to my PIN? (_oh i want that job!!_)
> Cheers
There is basically two ways to rob people or the bank
using an ATM. Either you hack into the ATM itself
(quite often a Windows machine), or you hack into
the ATM Processor (the back-end server on which all
the ATMs of the bank connect to).
If you hack the ATM you can grab customer's
card information _before_ they get encrypted.
There are a lot of funny attacks you can do too.
If you hack the ATM Processor, you can pretend
to be an ATM, and attempt to perform all sorts
of transactions.
In Singapore, one of the local banks at least will
_not_ be vulnerable to that (can't mention which one sorry),
they have a very strict security armada protecting their
ATMs/ATM Processors. The, rest? Who knows!
What I can tell you is that most of the banks do not
get third party hacking services to test their ATMs,
so it had to be expected that one day somebody
would abuse such trivial flaws. Serve them right
if you ask me, it's not like they've never heard
of security.
Shameless plug: I wrote a small presentation for
Hack In The Box Dubai, 2007, where I explain in more
details the attacks one can perform on ATM networks
(among other attacks):
tinyURL: http://tinyurl.com/5juyxb
or long one:
http://materials.hitbsecconf.org/hitbsecconf2007dubai/D1%20-%20Fabrice%20Marie%20-%20Robbing%20Banks%20-%20Easier%20Done%20Than%20Said.pdf
Have a nice day,
Fabrice.
--
Fabrice A. Marie
FMA Risk Management Solutions
http://www.fma-rms.com/
_______________________________________________
Slugnet mailing list
Slugnet@...http://wiki.lugs.org.sg/LugsMailingListFaqhttp://www.lugs.org.sg/mailman/listinfo/slugnet

(http://arstechnica.com/reviews/os/open-moko-software.ars)
I checked the store
(http://us.direct.openmoko.com/products/neo-freerunner). The
Freerunner version for the GSM 900 network (the GSM network used in
Sg.) were sold out...};-(
=====
First Look: OpenMoko's Linux-based open smartphone platform
By Ryan Paul | Published: July 08, 2008 - 11:30PM CT
Last Friday, OpenMoko launched its highly anticipated FreeRunner
smartphone, a Linux-based handset that's completely open in both
hardware and software, and is designed to encourage third-party
modification and customization. Although the FreeRunner's software
platform is still incomplete, the device has attracted considerable
attention from mobile software developers and Linux enthusiasts.
The FreeRunner handset is obviously a powerful tool for prototyping
mobile software, but it isn't clear yet whether it's also ready for
adoption as a personal smartphone. We won't have a conclusive answer
until we get a handset to test, but we decided to take an early look
at the OpenMoko software platform to get a glimpse of what it offers
at launch.
[...]
There are currently three separate software stacks that are available
for OpenMoko handsets. The original OpenMoko software environment was
built on top of GNOME Mobile and Embedded technologies including the
GTK+ toolkit. As the FreeRunner launch date approached and the
development priorities began to shift towards a stronger emphasis on
mainstream consumer adoption, OpenMoko reevaluated its approach and
decided to build a new stack on top of Trolltech's proven Qtopia
mobile environment. The third stack, which will implement the
FreeSmartphone.org APIs, is part of a long-term framework initiative
that OpenMoko hopes will eventually ameliorate the problems created by
fragmentation and redundancy while still offering developers a full
range of choices.
Because the FreeRunner is a completely open device, users will be able
to choose which platform they want to use. They will also be able to
adopt any third-party software platforms that emerge in the future. We
have already seen an impressive variety of Linux desktop environments
and graphical shells ported to Nokia's Internet Tablet devices, so it
is likely that we will see similar innovation on OpenMoko's handsets.
Indeed, developers of the KDE desktop environment have already started
working on experimental OpenMoko ports.
[...]
There are a lot of very significant differences between OpenMoko's
software stacks and Google's upcoming Android platform. Android takes
a more top-down approach and completely eschews native code. Android
offers one standardized Java-based API and One True Way to integrate
with its platform. Google's approach vastly simplifies development and
neatly avoids fragmentation and portability problems, but it also
imposes extreme constraints on flexibility, isolates Android-based
phones from the existing Linux software ecosystem, and obscures a lot
of the inherent strengths of a Linux-based platform. By comparison,
OpenMoko's software enthusiastically embraces the power and diversity
of Linux but does so at a high cost in performance, consistency,
reliability, and ease of development.
The OpenMoko platform strategy is clearly still evolving, but it has a
lot to offer for developers who want a truly hackable Linux-based
mobile phone that elevates freedom and choice. The biggest problem is
that none of the three stacks are really fully functional in every
respect at this stage of development. There are still gaps in
completeness and reliability that will deter end users who want a
smartphone that just works.
[...]
=====
--
--
Soh Kam Yung
my Google Reader Shared links:
(http://www.google.com/reader/shared/16851815156817689753)
my Google Reader Shared SFAS links:
(http://www.google.com/reader/shared/user/16851815156817689753/label/sfas)
_______________________________________________
Slugnet mailing list
Slugnet@...http://wiki.lugs.org.sg/LugsMailingListFaqhttp://www.lugs.org.sg/mailman/listinfo/slugnet

Google's Data Interchange Format Open Sourced

(http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html)
(http://code.google.com/apis/protocolbuffers/docs/overview.html)
(http://code.google.com/p/protobuf/downloads/)
=====
Protocol Buffers: Google's Data Interchange Format
Monday, July 7, 2008 at 3:01 PM
By Kenton Varda, Software Engineering Team
At Google, our mission is organizing all of the world's information.
We use literally thousands of different data formats to represent
networked messages between servers, index records in repositories,
geospatial datasets, and more. Most of these formats are structured,
not flat. This raises an important question: How do we encode it all?
XML? No, that wouldn't work. As nice as XML is, it isn't going to be
efficient enough for this scale. When all of your machines and network
links are running at capacity, XML is an extremely expensive
proposition. Not to mention, writing code to work with the DOM tree
can sometimes become unwieldy.
[...]
Instead, we developed Protocol Buffers. Protocol Buffers allow you to
define simple data structures in a special definition language, then
compile them to produce classes to represent those structures in the
language of your choice. These classes come complete with
heavily-optimized code to parse and serialize your message in an
extremely compact format. Best of all, the classes are easy to use:
each field has simple "get" and "set" methods, and once you're ready,
serializing the whole thing to – or parsing it from – a byte array or
an I/O stream just takes a single method call.
OK, I know what you're thinking: "Yet another IDL?" Yes, you could
call it that. But, IDLs in general have earned a reputation for being
hopelessly complicated. On the other hand, one of Protocol Buffers'
major design goals is simplicity. By sticking to a simple
lists-and-records model that solves the majority of problems and
resisting the desire to chase diminishing returns, we believe we have
created something that is powerful without being bloated. And, yes, it
is very fast – at least an order of magnitude faster than XML.
And now, we're making Protocol Buffers available to the Open Source
community. We have seen how effective a solution they can be to
certain tasks, and wanted more people to be able to take advantage of
and build on this work. Take a look at the documentation, download the
code and let us know what you think.
=====
--
--
Soh Kam Yung
my Google Reader Shared links:
(http://www.google.com/reader/shared/16851815156817689753)
my Google Reader Shared SFAS links:
(http://www.google.com/reader/shared/user/16851815156817689753/label/sfas)
_______________________________________________
Slugnet mailing list
Slugnet@...http://wiki.lugs.org.sg/LugsMailingListFaqhttp://www.lugs.org.sg/mailman/listinfo/slugnet