Posted by on under new radio, opti, bug fixes, hud, french german, new features, norwegian, crash | 
New Features
- New radio player HUD contributed by Smooquai
- New radio icons contributed by CompC
- Add an option to queue tracks while device is asleep
- Updated French, German, Italian, Norwegian, and Russian translations
Bug Fixes
- Fix a crash that can occur when playing a non-existant playlist
- Fix a crash that can occur when the last.fm server is unreachable
- Stop caching playlists
- Improved detection of duplicate scrobbles
Head on over to the
MobileScrobbler website for installation instructions, screenshots, and more!
Tagi: new radio, opti, bug fixes, hud, french german, new features, norwegian, crash
Posted by on under repository code, versis, custom html, test zip, zip archives, search server, repositories, opti, t test, copy paste, cfig, pear, goodness, parameters, peoe, array, exec, circumstances, beta, search engine |
Hi!
Proudly presenting you the new beta of
Installer -
4.0b6.
New and changed:
- Search. It searches among packages from the repositories you have added, and, if you let it sit for 5 seconds, will query our server and return packages that are available from repositories you don't have added (that we know about) with an option to automatically add and install. Repository owners, upgrade to the latest version of the repo code (below) to have your repository added to the search engine.
- Uninstall now works correctly.
- Fixed a lot of locking issues especially with custom HTML info pages.
- Updated the Categories and Tasks icons so they are less ugly.
- Fixed a bug with multiple copies of Installer appearing in Installed Packages under some circumstances.
- Installer will now correctly check and prompt for an update of itself.
Also, to accompany the Installer release, a new edition of the Repository code is up. Grab it here:
repo-r1114.zipWhat's new in the repo code?
- Added an option to ping the Installer search server so it reindexes your repository. The ping occurs during regenerate.php run.
- Much better handling of ZIP archives, since this is what most people had troubles with. It now attempts to determine which way to use to unzip your files (PEAR::ZipArchive, zip_open or shell_exec("unzip")). Please note that we didn't test zip_open piece of the code as we don't have a server with that plugin compiled in PHP.
- DOMDocument::load() should work under PHP4. We hope.
- Slightly better handling of the multiple versions of the same package.
How to upgrade? Simply replace regenerate.php with the new one, and add new configuration parameters from config.inc.default.php to your config.inc.php. There are two: REPOSITORY_URL, that should have a full path to your repo (with a trailing slash), and ZIP_CMDLINE_PATH (only add this if needed). Refer to config.inc.default.php for the descriptions and copy-paste goodness.
Don't forget to regenerate your repositories once upgraded, and also don't forget to put 2.0.2 into POSSIBLE_FIRMWARE_VERSIONS array so people on the new firmware can see your packages!
Thanks. :)
Tagi: repository code, versis, custom html, test zip, zip archives, search server, repositories, opti, t test, copy paste, cfig, pear, goodness, parameters, peoe, array, exec, circumstances, beta, search engine
Posted by on under iphe, iphone, opti, 2g, flatrate, 3g, modem |
Created by marcoxyz 10 weeks ago: "iPhoneModem.app provides the easiest and safest way to use your iPhone as a modem to connect you to the internet. Despite the the unsafe connection bewteen your Mac and your iPhone your data are safe because all communication between both devices are encrypted by SSH.
Everybody who does not want to use the terminal but need the option to work with your provided flatrate like you can do with other cell phones, too. iPhoneModem works with all jail broken iPhones 2G and 3G over EDGE and UMTS. have..."
Read the rest of this post
Tagi: iphe, iphone, opti, 2g, flatrate, 3g, modem
Posted by planetbeing on under command line interface, candy thanks, boot menu, menu graphics, somee, eye candy, banging my head, working model, opti, bleeding edge, iboot, userland, gimp, grub, ibot, butt |
Well, that was quick. See, I can actually get things done pretty quickly when it doesn't consisting of banging my head against machine code until it starts making sense. When I actually have the drivers, things like this are easy.
You can use the Hold button to toggle between the menu items (and the option will be highlighted). You can choose the home button to select it. The "openiboot console" option takes you to the command-line interface similar to the one I demonstrated in the last post (you do have to be plugged in via USB and using the openiboot client to talk to it). The "iPhone OS" option chainloads a copy of iBoot stored in NOR under another identifier ('ibot' becomes openiboot and 'ibox' becomes the actual iBoot). I got that set up with a slightly modified version of the QuickPwn ramdisk, but in the future an installer made from a modified version of LogoMe can be run from userland to install openiboot. It's also possible to get openiboot to install openiboot (much like the way GRUB can do it); I'll probably work on that next.
So if anyone likes living on the bleeding edge, they could do that. =P
Most of the hard part was me failing at GIMP putting together the boot menu graphics. I appealed to you blog readers for graphics before, but basically no one responded. Now that there is a working model of what I sort of want, I hope there will be more of a response.
So,
please please please redesign the boot menu for me. And possibly come up with a logo for the project we can stick on there. If you're good at this sort of thing, or know someone who is, please put them in touch. This stuff will obviously get a lot of attention in the future and we need nice eye-candy. Thanks!
Tagi: command line interface, candy thanks, boot menu, menu graphics, somee, eye candy, banging my head, working model, opti, bleeding edge, iboot, userland, gimp, grub, ibot, butt
Posted by planetbeing on under clock timer, iphe, day clock, versis, linux kernel, cpu x86, boot menu, linux drivers, mmu, android, opti, whirl, wi fi, graft, spi, knowledge gained from, many things, timers, vic, clocks |
I've been getting a lot of questions from people that seem to reflect a basic misunderstanding of what it takes to port an operating system onto a new platform. People seem to think that just by writing, say, a boot menu, means that we can stick Android or Windows or whatever onto a device because we can have a menu option for it.
Here's what it takes for an
operating system to run on a device:
- The code must be designed for the right CPU. (x86, ARM, PPC)
- The code must be able to interact with the hardware in the way it expects.
Now, there are versions of Linux compiled in ARM (which the iPhone uses), there are even versions of Windows Mobile that are compiled in ARM. Why can't I, then, just stick Windows Mobile or Android (or another flavor of Linux) onto the iPhone and give it a whirl?
Because the code cannot interact with the hardware! That is, there are no Linux drivers or Windows Mobile drivers for the hardware that's on the iPhone. We're not even talking about things like the wi-fi won't work or anything silly like that. We're talking about big things, like not being able to start because it doesn't uncompress itself into RAM properly. We're talking about freezing the first time it has to wait for something to happen because it doesn't know how to run the hardware clocks and timers (which is CRITICAL for computers) and doesn't know when to start again.
Thus , if I tried to take some distribution of Linux or Windows or whatever, stick it in memory and start it, absolutely nothing will happen. That's right: nothing. There will be no output because it doesn't know how to run the display, or the USB, or serial. It probably won't even get to the first line of code that tells it to output something because so many things are broken.
So how can we get Linux to boot on the iPhone?By teaching it how to run the hardware. We take the knowledge gained from getting that boot menu to display and graft it into the Linux kernel. It took an unbelievable amount of devices just to get the boot menu display: clock, timer, vic, mmu, spi, i2c, gpio, system controller, pmu, nor, uart, usb, lcd, buttons. Some of those may seem obvious to you, some work in the background to support the other devices. But all of those had to be reverse engineered and all of them will have to transplanted into the Linux kernel to even get something half-assed booting.
If all of those devices were required to get something as simple as boot menu up, can you imagine what would happen if you tried to boot an operating system that did not know how to run ANY of those devices?
We cannot modify the Windows Mobile kernel because it's closed source, and so there's no way to get it to run on the iPhone.
The critical misunderstanding, I think, is that people think somehow that the OS "sits on top" of the boot menu, and talks to the hardware through the boot menu. Therefore, you can have an "emulation layer" that lets Windows or Linux or whatever talk to the hardware, without having to alter Windows or Linux itself. This is completely false. An operating system, by definition, has direct access to the hardware. Nothing sits between it and the hardware. Once iBoot has loaded the iPhone OS, you can go ahead and wipe it clean from the NOR and the OS will keep running as usual. It's not "running", it's not used or loaded in any way except during the boot process.
The iPhone will never run Windows Mobile directly (virtualization would be possible albeit it would crawl on the iPhone). It will run Linux once we write the drivers for it based on our knowledge of the hardware. Android uses the Linux kernel, though they do modify it to a certain extent. Since the only really hardware dependent parts of an OS is in the kernel, presumably once we install the necessary drivers, Android will run just as well as Linux runs. However, not having even looked at Android's source yet, I really don't have a truly educated opinion at the moment, but let's just say that it's one of this project's primary goals.
Sorry this is so long, but intelligent explanations tend to be long.
P.S. Another question people ask a lot is how long will it take. I can't truly give a good answer to that, because it's sort of dependent on the schedules of the people who work on it, and it also depends on how fast it'll take to write the Linux drivers, and how many unexpected problems crop up. It could go really unexpectedly fast, or we could hit a roadblock. I think outside observers, just reading the commit logs and reading the blog has as much information as I do on how fast things are progressing, so you're free to come up with your own conclusions on how long it will take.
Tagi: clock timer, iphe, day clock, versis, linux kernel, cpu x86, boot menu, linux drivers, mmu, android, opti, whirl, wi fi, graft, spi, knowledge gained from, many things, timers, vic, clocks
