If you're on Sprint, try the Sanyo SCP 4900. With the extended battery and in areas with decent service, you won't have to charge it more than once a week; it's decently rugged; and you can pick one up for $30 on ebay. It was a top-of-the-line phone...around 2003.
In this case, though, if you're willing to mess with the disk controller and do some physical hacking, you could eliminate the challenge-response system, or have it authenticate with any response. Probably won't be easy, though.
Still, since the drive controller would still be doing the decryption, Bob's your uncle -- it doesn't matter how secure the algorithm is.
And the algorithm? It's an SHA-1 hash of the password XORed with the challenge. SHA-1 has a complexity of 2**63 to find collisions, which isn't very good. Capture one challenge/response pair, and within a couple months with a decent botnet / @home network, you can have your password.
O'course, since each Tivo probably has a different password, that's not particularly useful. Hardware hacking will probably be quicker and easier in the end.
Most desktop users on Unix only run a few proprietary applications at most: maybe a couple of Windows games (via Cedega or Wine), Opera, and video drivers. Windows games probably won't be able to use gdb on your Unix system; Opera actually is your web browser, so it doesn't need to attach gdb to itself to find your password; and the video drivers are running higher than root.
Of course, you could use SELinux and its application roles. That might help.
If you're willing to restrict yourself to.NET 1.1 (with C# 2.0 and ASP.NET 2.0), you've got Mono for Apache. Now if only I could get an IDE that offers the features of Visual Studio but was stable, didn't run like shit with 2GB of RAM and a 3GHz processor, and ran on Linux.
The UK government registered co.uk and allowed other people to register *.co.uk subdomains as if.co.uk were a TLD. I can't register aa.uk, for instance, the grandparent claimed.
Compared to its peers back in the 70's, Unix was buggy and slow. So why did it succeed?
- It had a good model of the machine: everything's a file.
- It was easy to write code for: it used C.
- It was portable (see previous).
If we were primarily concerned with security, we'd be using VMS. But security gets in the way.
Yeah, all three examples of patches not being accepted had to do with XML, and it's entirely possible (and reasonable) to think that XML might not be the best format for Blender to output. Not to mention, just because the file format is still binary doesn't mean there's no progress.
What benefit could GNOME possibly derive by examining the guts of filesystem drivers? Make the filesystem more efficient, and everything on the system benefits.
The same with an init system: it just has to run shell scripts. Granted, if it knew how fast each filesystem was, it could try to optimize the order, but it doesn't need to know about the filesystem driver to do that -- it'd be of more benefit to know about the devices and the buses they're on. And that's probably possible with udev.
That rant, by the way? It specifically concerned the disk scheduler. If a batch read call were available to the filesystem drivers and they made use of it, then the scheduler could arrange to read more files per scan. That's not a layering violation.
To be more polite, it's unlikely that I can assemble a collection of software that meets your needs unless your needs are mundane or I spend my time polling you for your particular requirements. The latter produces a result that's only useful for you. It doesn't make sense for me to be your personal sysadmin, but it does make sense for me to supply a default configuration for my hypothetical Linux distro that supplies most common needs.
So you can supply your own needs, as long as the Linux distro you use makes that reasonably simple. And it's simpler in Linux than Windows, in my opinion, with no worries about random binaries containing trojans and the like.
Windows has DirectX, which is a single library supporting just about everything your game needs, and all under a relatively standardized interface. Linux has a disparate group of libraries by multiple groups with no guarantee about consistency.
The closest equivalents on Linux, that I've heard of, are SDL and Allegro. Neither are useful for modern games.
Solution: have the simple view by default. Let the user click the "Advanced" button to show advanced settings. It takes two seconds of the user's time, though the programmer has to spend an extra day or so creating the default view and settings.
You could just have the application find sane defaults for the system and just present all the options, which is what KDE does. That usually seems cluttered and unappealing to me, but it works.
My god, Microsoft made an option for their displays that takes more processing power, and using it drains your battery quicker! Such a feat of poor engineering!
That's entirely hypothetical. It would be a driver issue, though, so it's testable, within some margin: write a replacement driver for the Mac, and then port it to Windows. Compare performance between the two.
Still, you're being paranoid, and just taking an opportunity to make a crack at Macs. I don't think you believe you have a valid point.
So you fool around with it, examine every menu entry and every option, and document their effects one at a time. Then you have a reference for yourself, but it's in reverse: command to task rather than task to command. Just flip it around and you're done. (The flipping might take significantly longer than the initial exploration, though.)
Then approach the developer with the documentation in hand. Better yet, find out what GUI toolkit the project uses, what sort of help system is offered, and what file format that system uses. Then format your documentation according to that system and offer the developer the formatted version.
It helps, though, if you offer to maintain the documentation. That way, bugs in the docs don't affect the developer.
You can't invent a standard object format because it's only meaningful for a limited set of applications. The rest, well, you can sort and display based on fields, but you can do so with awk. With this, you just need to know the name of the field rather than the number of the column. And that's about it.
General purpose tools now have to convert things to text or create some mapping between generic objects and particular objects. Or you have to implement objects as dictionaries, and just treat the field names as meaningless keys (which they pretty much are).
I'm sorry, I just don't see much use. It's like template metaprogramming: probably useful in some edge cases, but probably not revolutionary for the average user.
On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager. For this task (networked cameras), you need ifconfig, a dhcp client, maybe a stripped Apache, and your custom application. And you can probably incorporate ifconfig / dhcp functionality into a library (take them from BSD or something licensed under LGPL) and put them in your application, which could also handle init if space is tight. (Though you probably don't want this, in case your appliance has to be reset.)
In short, while you can use Gentoo to build your target system, it won't effectively be Gentoo by the time you're finished. And it doesn't matter which distribution you choose at that point.
Hierarchical data stores? You mean like putting config files into a directory structure, or having XML-based config files? Everything's text, it's just how you arrange and interpret it.
Script signing sounds like something I'll never need. It's rare enough that some random developer has the funds lying around to pay a signing authority to sign their stuff that I wouldn't take the lack of signing to be indicative of anything, and most of the signing authorities just sign anything that comes with enough money, so if I get a signed script, that doesn't mean it's secure.
Text is universal, though, and it lets you have a single means of output for simpler programs. Want to read the results immediately? Just call the program. Want to save the results? Dump them to a file to review later.
This makes it trivially easy for programmers to modify the output, or for the users to use it in unexpected ways. It means we don't need a separate program to convert binary data to a human-readable form first.
Complex datatypes in a shell are only good if you're using a set of languages that can deal with the same objects. With Unix, not all your languages have a concept such as an object -- not even a struct. Even then, you need a human-readable form for them, even if they're converted at the user's request.
As long as Monad has that, it's probably decent. But that's going to be application-specific.
The OLPC interface was optimized for the machine. From the screenshots I saw, it didn't take up much space with textures and such; just about everything could be drawn with a minimal amount of SVG, which means you can spend slightly more CPU time and save on RAM.
Also most of the applications are more or less custom, designed or modified to save on RAM and CPU time. Windows XP...could be, but I somehow doubt it would be that easy. If they said it was based on Windows Mobile, I'd be less skeptical.
If I run OpenOffice and you run OpenOffice, there's only one copy of OpenOffice in memory, but using twice the heap space (as much as you would be using alone and as much as I would be using alone). So you need less than twice the RAM.
Well, okay, I'm not sure how that works with jvm. But with standalone binaries, it's true; with shared libraries, it's true.
You're conflating technology with support. I don't need Linus Torvalds to own a Linux support company; I can purchase my support from Canonical or Red Hat or Novell or dozens of others.
If Linux will succeed on the popular desktop, then it will come preinstalled. It will come with manufacturer support -- or the manufacturer will have a support contract with another agency. And that won't be much cheaper than OEM Windows. (So incidentally, Linux only has a price advantage for people who can forgo support.)
It goes on to say that Linux is a threat because it's good (and presumably because it's a competing product). So open source is a threat when MS offers a similar product and the open source product is reasonably good.
Slashdot Mirror
If you're on Sprint, try the Sanyo SCP 4900. With the extended battery and in areas with decent service, you won't have to charge it more than once a week; it's decently rugged; and you can pick one up for $30 on ebay. It was a top-of-the-line phone...around 2003.
Only issue: you can't send text messages with it.
In this case, though, if you're willing to mess with the disk controller and do some physical hacking, you could eliminate the challenge-response system, or have it authenticate with any response. Probably won't be easy, though.
Still, since the drive controller would still be doing the decryption, Bob's your uncle -- it doesn't matter how secure the algorithm is.
And the algorithm? It's an SHA-1 hash of the password XORed with the challenge. SHA-1 has a complexity of 2**63 to find collisions, which isn't very good. Capture one challenge/response pair, and within a couple months with a decent botnet / @home network, you can have your password.
O'course, since each Tivo probably has a different password, that's not particularly useful. Hardware hacking will probably be quicker and easier in the end.
Most desktop users on Unix only run a few proprietary applications at most: maybe a couple of Windows games (via Cedega or Wine), Opera, and video drivers. Windows games probably won't be able to use gdb on your Unix system; Opera actually is your web browser, so it doesn't need to attach gdb to itself to find your password; and the video drivers are running higher than root.
Of course, you could use SELinux and its application roles. That might help.
If you're willing to restrict yourself to .NET 1.1 (with C# 2.0 and ASP.NET 2.0), you've got Mono for Apache. Now if only I could get an IDE that offers the features of Visual Studio but was stable, didn't run like shit with 2GB of RAM and a 3GHz processor, and ran on Linux.
The UK government registered co.uk and allowed other people to register *.co.uk subdomains as if .co.uk were a TLD. I can't register aa.uk, for instance, the grandparent claimed.
Small credit unions will absolutely love the $50k price tag....
Compared to its peers back in the 70's, Unix was buggy and slow. So why did it succeed?
- It had a good model of the machine: everything's a file.
- It was easy to write code for: it used C.
- It was portable (see previous).
If we were primarily concerned with security, we'd be using VMS. But security gets in the way.
Issue: quality control.
Yeah, all three examples of patches not being accepted had to do with XML, and it's entirely possible (and reasonable) to think that XML might not be the best format for Blender to output. Not to mention, just because the file format is still binary doesn't mean there's no progress.
What benefit could GNOME possibly derive by examining the guts of filesystem drivers? Make the filesystem more efficient, and everything on the system benefits.
The same with an init system: it just has to run shell scripts. Granted, if it knew how fast each filesystem was, it could try to optimize the order, but it doesn't need to know about the filesystem driver to do that -- it'd be of more benefit to know about the devices and the buses they're on. And that's probably possible with udev.
That rant, by the way? It specifically concerned the disk scheduler. If a batch read call were available to the filesystem drivers and they made use of it, then the scheduler could arrange to read more files per scan. That's not a layering violation.
To be more polite, it's unlikely that I can assemble a collection of software that meets your needs unless your needs are mundane or I spend my time polling you for your particular requirements. The latter produces a result that's only useful for you. It doesn't make sense for me to be your personal sysadmin, but it does make sense for me to supply a default configuration for my hypothetical Linux distro that supplies most common needs.
So you can supply your own needs, as long as the Linux distro you use makes that reasonably simple. And it's simpler in Linux than Windows, in my opinion, with no worries about random binaries containing trojans and the like.
Windows has DirectX, which is a single library supporting just about everything your game needs, and all under a relatively standardized interface. Linux has a disparate group of libraries by multiple groups with no guarantee about consistency.
The closest equivalents on Linux, that I've heard of, are SDL and Allegro. Neither are useful for modern games.
Solution: have the simple view by default. Let the user click the "Advanced" button to show advanced settings. It takes two seconds of the user's time, though the programmer has to spend an extra day or so creating the default view and settings.
You could just have the application find sane defaults for the system and just present all the options, which is what KDE does. That usually seems cluttered and unappealing to me, but it works.
My god, Microsoft made an option for their displays that takes more processing power, and using it drains your battery quicker! Such a feat of poor engineering!
That's entirely hypothetical. It would be a driver issue, though, so it's testable, within some margin: write a replacement driver for the Mac, and then port it to Windows. Compare performance between the two.
Still, you're being paranoid, and just taking an opportunity to make a crack at Macs. I don't think you believe you have a valid point.
Record everything you explain to them. That way, as long as what you say doesn't go out of date, you only have to find what you wrote.
And, hey, slap an index on it and you can call it your documentation.
So you fool around with it, examine every menu entry and every option, and document their effects one at a time. Then you have a reference for yourself, but it's in reverse: command to task rather than task to command. Just flip it around and you're done. (The flipping might take significantly longer than the initial exploration, though.)
Then approach the developer with the documentation in hand. Better yet, find out what GUI toolkit the project uses, what sort of help system is offered, and what file format that system uses. Then format your documentation according to that system and offer the developer the formatted version.
It helps, though, if you offer to maintain the documentation. That way, bugs in the docs don't affect the developer.
You can't invent a standard object format because it's only meaningful for a limited set of applications. The rest, well, you can sort and display based on fields, but you can do so with awk. With this, you just need to know the name of the field rather than the number of the column. And that's about it.
General purpose tools now have to convert things to text or create some mapping between generic objects and particular objects. Or you have to implement objects as dictionaries, and just treat the field names as meaningless keys (which they pretty much are).
I'm sorry, I just don't see much use. It's like template metaprogramming: probably useful in some edge cases, but probably not revolutionary for the average user.
On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager. For this task (networked cameras), you need ifconfig, a dhcp client, maybe a stripped Apache, and your custom application. And you can probably incorporate ifconfig / dhcp functionality into a library (take them from BSD or something licensed under LGPL) and put them in your application, which could also handle init if space is tight. (Though you probably don't want this, in case your appliance has to be reset.)
In short, while you can use Gentoo to build your target system, it won't effectively be Gentoo by the time you're finished. And it doesn't matter which distribution you choose at that point.
Hierarchical data stores? You mean like putting config files into a directory structure, or having XML-based config files? Everything's text, it's just how you arrange and interpret it.
Script signing sounds like something I'll never need. It's rare enough that some random developer has the funds lying around to pay a signing authority to sign their stuff that I wouldn't take the lack of signing to be indicative of anything, and most of the signing authorities just sign anything that comes with enough money, so if I get a signed script, that doesn't mean it's secure.
Text is universal, though, and it lets you have a single means of output for simpler programs. Want to read the results immediately? Just call the program. Want to save the results? Dump them to a file to review later.
This makes it trivially easy for programmers to modify the output, or for the users to use it in unexpected ways. It means we don't need a separate program to convert binary data to a human-readable form first.
Complex datatypes in a shell are only good if you're using a set of languages that can deal with the same objects. With Unix, not all your languages have a concept such as an object -- not even a struct. Even then, you need a human-readable form for them, even if they're converted at the user's request.
As long as Monad has that, it's probably decent. But that's going to be application-specific.
The OLPC interface was optimized for the machine. From the screenshots I saw, it didn't take up much space with textures and such; just about everything could be drawn with a minimal amount of SVG, which means you can spend slightly more CPU time and save on RAM.
Also most of the applications are more or less custom, designed or modified to save on RAM and CPU time. Windows XP...could be, but I somehow doubt it would be that easy. If they said it was based on Windows Mobile, I'd be less skeptical.
If I run OpenOffice and you run OpenOffice, there's only one copy of OpenOffice in memory, but using twice the heap space (as much as you would be using alone and as much as I would be using alone). So you need less than twice the RAM.
Well, okay, I'm not sure how that works with jvm. But with standalone binaries, it's true; with shared libraries, it's true.
You're conflating technology with support. I don't need Linus Torvalds to own a Linux support company; I can purchase my support from Canonical or Red Hat or Novell or dozens of others.
If Linux will succeed on the popular desktop, then it will come preinstalled. It will come with manufacturer support -- or the manufacturer will have a support contract with another agency. And that won't be much cheaper than OEM Windows. (So incidentally, Linux only has a price advantage for people who can forgo support.)
It goes on to say that Linux is a threat because it's good (and presumably because it's a competing product). So open source is a threat when MS offers a similar product and the open source product is reasonably good.
How is open source not a threat to them again?