63
I Use This!
Very High Activity

News

Analyzed about 22 hours ago. based on code collected 2 days ago.
Posted over 12 years ago by sgarman
The Yocto Project's developers have been working hard to improve the usability of our software, especially its "out of the box" user experience. One area that has admittedly been a thorn in our side is when users need to access the internet via a ... [More] network proxy server*. I thought I'd take a few moments to explain the situation, why we don't have a "silver bullet" solution yet, and how to work around it. If your personal or corporate network doesn't require you to use a network proxy to access the Internet, consider yourself lucky. Proxies complicate network communications, requiring special protocols (such as SOCKS) to pass your development computer's packets out to the Internet and back. And while the "do one thing and do it well" design philosophy of Linux/Unix programs has allowed these utilities to weather the test of time extremely well, there is no universally adopted method of modifying the networking behavior of these programs when it comes to using proxies. Here are but a few methods Linux programs can be made to use a proxy server: Some utilities check for a special environment variable (HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, etc) Many desktop applications (e.g, GNOME apps) look for a proxy settings key in their global desktop registry Others (like Subversion, or Mozilla Firefox) have their own config files or internal configuration dialogs where you have to specify proxy settings Finally, some programs don't contain any code for working with network proxies at all! In this case, you can sometimes get away with running the program under a separate, wrapper program which intercepts its network communications and automatically routes them through your proxy (tsocks is one of these wrapper programs) I'm reminded of the saying: "Standards are like toothbrushes - everyone has one, but no one wants to use anyone else's." Truth be told, there is really no single solution to the proxy problem. Another issue that poses problems for Yocto Project developers is that many of the proxy configurations for various tools (such as Subversion) are stored in the user's own home directory. And modifying configuration files in your home directory is not something that will endear us to many users. So what do you need to do to work with the Yocto Project behind a network proxy? Rather than filling this blog post with configuration tips, I'll refer you to our wiki page, Working Behind a Network Proxy, where we make every effort to keep up to date with configuration tweaks needed for network proxy users. If anyone can devise a way of reliably automating this process into a support script we could ship with the Yocto Project, we would be very open to including it. Just keep in mind that the script's actions cannot clobber other config customizations a user may have, and would need to be fully reversible, to work for users who need to move in and out of proxied network environments. * Note: a network proxy is different from a "firewall" - Yocto builds should work fine when run from behind a typical firewall router. Sometimes the terms "proxy" and "firewall" are used interchangeably, but they are quite different concepts. [Less]
Posted over 12 years ago by dvhart
Wrapping up things for the upcoming Yocto 1.1 release tends to keep us all heads down hammering away. Let me take a momemnt to share what I've beeing working on. We are fortunate to have a base kernel version alignment between Yocto and the ... [More] PREEMPT_RT tree. Yocto 1.1 will include a refreshed real-time kernel and I have expanded real-time support to all the meta-intel BSPs as well as several of those from oe-core and meta-yocto. Beyond the release, I have been trying to get my teeth into building truly small and fast images. While our current core-image-minimal image is by no means heavy-weight by current standards, those handful of megabytes receive heavy scrutiny from the folks in SoC land where DRAM cells are the shopping malls of die real-estate. Cutting the kernel down in size can be largely accomplished with a carefully crafted Linux kernel .config. Managing these for more than a few machines however, is tedious... at best. Fortunately, others are interested in cutting back on defconfig bloat in the kernel and I helped lead a Linux kernel config fragment management BoF session at the recent Linux Plumbers Conference. John Stultz has posted his merge_config.sh script for review on LKML following that session. Better fragment management will be an important tool for maintaining .config files across multiple BSPs. As a sibling project to reduced image size, I'm looking at bringing down image boot time. Kernel size and features can have a significant impact on your boot time, especially on slower media, like MMC over SDIO which is so common in the embedded space.  Of course, userspace plays a big part in boot time as well. Fortunately, my extended team is also looking into that. I'll have more details for everyone in October. I better, they already put me on the schedule at ELCE! [Less]
Posted over 12 years ago by davest
We finished up all of our expected feature development on the Yocto Project version 1.1, due out in October. After some stabilization and bug fixing, we're encouraging everyone to try out our bits. Would you check it out? You just need a Linux system ... [More] (a recent release of Fedora or Ubuntu works best) and the necessary workarounds for git and http to work with any network proxy you might have. (Instructions for this are below). Check out the Hob, our visual build user experience and let us know what you think.Use our normal communication channels ([email protected] or #yocto on freenode) if you need help. We would be really happy if you would use Bugzilla to file any bugs you find: http://bugzilla.yoctoproject.org Thanks!     1. Configure proxy settings if you work behind a firewall, please follow the instructions here: https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy   2. Go to the Yocto website at http://www.yoctoproject.org.   3. Follow the instructions at http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html to build and boot an example image (‘The Packages’ and ‘Building an Image’ section in the guide). Since the quick start guide at the above link has not been updated for Yocto 1.1 release, please make the following changes when you follow the steps listed in the guide: a. Replace: $ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2 $ tar xjf poky-bernard-5.0.tar.bz2 $ source poky-bernard-5.0/poky-init-build-env poky-5.0-build   with:   $ wget http://git.yoctoproject.org/cgit/cgit.cgi/poky/snapshot/poky-f8cddd74574756174a82c856cecdeb6f83b9dea5.tar.bz2 $ tar xjf poky-f8cddd74574756174a82c856cecdeb6f83b9dea5.tar.bz2 $ mv poky-f8cddd74574756174a82c856cecdeb6f83b9dea5 oe-beta $ source oe-beta/oe-init-build-env oe-beta-build   b. Replace:   $ bitbake -k poky-image-sato   with   $ bitbake -k core-image-sato   c. Replace:   $ poky-qemu qemux86   with:   $ runqemu qemux86   4. Using the instructions provided, create an image for one of the architectures supported in the QEMU emulator. (This is the bitbake core-image-* command.) This step may take up to 6 hours. If you would like to spend less time here, you could also try to build ‘core-image-minimal’ instead of ‘core-image-sato’. Monitor the build for failures and ask for assistance on the #yocto IRC channel on freenode.net in order to successfully complete the build.   5. Boot the resulting image under QEMU (the runqemu command).   6. HOB is our GUI based image creator. After you have followed the above steps, you could try HOB simply with the following command:   $ hob   Generated images by HOB should be in ‘tmp/deploy/images’ under the current directory. Please check out this wiki page for more information about HOB: https://wiki.yoctoproject.org/wiki/BitBake/GUI/Hob [Less]
Posted over 12 years ago by davest
I was just in Los Angeles this week for a few days of holiday with my family. With apologies to the Angelinos who might read this post, we got an excellent exposure to the local culture: Traffic snarls, over-the-top personalities in restaurants, loud ... [More] vocal complaints about "tourists" and agressive negotiations. "Agressive negotiations" are constantly on display in the competition for parking spaces. On-street parking meters in Beverly Hills (ah, those heavenly hills in zip code 90210) are now able to take credit cards. Seriously, the traditional coin meter is about the last annoying need for small pocket change that I never seem to have on me. So I for one welcome our new credit card masters. Other cities like Prague and Portland have taken a slightly different approach - instead of individual meters for each space, a city block is covered by a larger machine that produces a paper receipt which is then posted inside the parked car's window. Here is a shot I took of the Prague version in 2008: The Prague and Portland version have a "green" edge in that they are solar powered, but since they depend on a printed paper tag to be produced, they seem more prone to breakdown and lost their green cred as well. And the LA meter seems better suited to a town where nobody (and I mean nobody) walks anywhere. No need to walk as much as a half block to a common parking machine; just pop out of your car and plug your platinum card into the slot.  But as I have written before on this blog, the door is now wide open for municipalities to provide interesting services with more advanced embedded computing. For example, I noticed that there are a lot of very expensive cars in Beverly Hills. Why not offer (for an additional fee of course) to watch your car to make sure it isn't vandalized or sideswiped? With just a motion sensor, keypad for an unlock code and a wireless phone connection, this service could be offered for permanent residents of the city, thus giving you another reason to snub the tourists. Fortunately, I had coins available from my wife to use in the meter, so I didn't need to trust my credit card credentials to such an easily hacked device. I better stop here before I can no longer travel through LAX. [Less]
Posted over 12 years ago by davest
A couple of months ago, the Yocto Project reached a kind of strange milestone. Some of my friends like Bill Mills suggested I should be blogging about it, but for some reason it was hard for me wrap my head around it. Here's my attempt. It was on May ... [More] 19, 2010 that someone sent an email (Hi, Sven!) suggesting the name "Yocto" for our new embedded Linux project. We had been really struggling to come up with a good name, something which would not be offensive in other languages and which was not already taken. A year later, when you google the term "yocto", the first result listed is the Yocto Project website rather than the definition of the scientific term.  Granted, the "yocto-" prefix is not the most commonly used scientific term, and I'm not sure how many of the uses of the scientific yocto prefix link link back to the Wikipedia page. Google ranks its search results based on some proprietary and ever-changing algorithm, but I have heard that it's based on the number of pages that link to yoctoproject.org. So this does represent a bit of a threshold or tipping point of awareness of the project on the internet. Huzzah! Personally, though, I've never felt really comfortable with the idea of getting big just to be big. There is a danger to it. You set expectations that may not be realistic, and you may find yourself having grown too big and needing to retrench or reset expectations.  In the US, we call this getting "too big for your britches" for some unknown etymological reason. So I dislike anything which sniffs too much like hype. I would rather offer something of true value to people, and when people learn about it, they will want to take advantage of it. But at the same time, without the awareness which comes with being big, you might never reach the audience who could benefit the most from what you are doing. There is a beneficial reinforcing cycle which kicks in when there is awareness which comes from size. I took a job 25 years ago at a little technology startup. The company started hiring a bunch of people and I remember telling a manager there that I was a bit nervous about the company getting too big. His response was, "If you don't think we should grow, then you should be getting your resume together about now." Implying of course that in order to survive and make an impact, we really did need to grow and I needed to get on board with this or find someplace else to work. I'm still resistent to give in to hype. It's tough because I have a lot of enthusiasm for embedded Linux and the Yocto Project. But  I'm not afraid to be bigger.   (For the sake of completeness, as of the time of this writing, bing.com and yahoo.com still had the project below the scientific term. For now!) [Less]
Posted over 12 years ago by davest
 Today we dropped another development milestone build for the Yocto Project. Introducing the M2 build. Our intent for these regular milestone drops is to synch up everything in the project and pause feature develoment, stabilize the software through ... [More] some QA runs and bug fixing, and make it available to you, the community. This way you can evaluate the progress we have made, help identify and/or fix bugs and accelerate us to completion. It's also a way for us to be totally transparent in the project. (And in the interest of complete transparency, I need to confess that I'm writing this in a little rental house on the Oregon coast, where at least part of my family is visiting with friends from college and their kids. For the Oregon beach, the weather is amazingly good - no wind, sun blazing away. But the sun, surf and sand does not excuse me from getting a blog post done). Beth Flanagan gave a very good description of our M2 release on the Yocto Project mailing list. I thought I would highlight a couple of important features which are available now: The Hob - As we have announced previously, we providing in the next release a user experience which provides access to the build system without editing a bunch of text files and running a command-line program. Now it's possible to do most system development tasks from within the UX. Our goal is for any regular system developer to develop their custom OS quicker than working without it. (More below on a couple of warnings for using this version). Joshua Lock has been the lead on this feature, though there are many others contributing as well. Check out this wiki page for some rough info about Hob and its various cohorts. Layer Tools - This is a major extension of the Yocto Project to make it easy to develop independent layers. These can be maintained in separate repositories and combined together into a single distribution, you get enhanced warnings and notices when something seems messed up in yourlayer setup. And remote layers are supported now, thanks to an important contribution from Montavista. There are a number of features and improvements. Paul Eggleton has spearheaded this feature although there are many others who have contributed. There are other important features and updates and performance improvements in this milestone, along with a number of bug fixes. Check Beth's release notes for details. A word on this version of the Hob: There are a couple of issues which are present in this version, and which are being fixed. These are eay to work around, and we would appreciate it if you would try out this version with these caveats and give us your feedback. First, before you try the Hob, we recommend that you do a bitbake build of an image from the command line. Then, Hob should work fine for generating images. So if the build directory is new, I recommend that you do: $ bitbake core-image-minimal before you try to use Hob. Second, there is a problem if you disable packages in Hob. Some of the code paths work, but there are several which do not. Best bet for the M2 version of Hob is not to play with package disabling. This should be fixed in the M3 version, which should be coming out in a few weeks. Launching the Hob in the M2 version is as simple as typing $ bitbake -t xmlrpc -u hob ... once you have sun the usual environment setup script and done a minimal image build, as mentioned above.  This will be even simpler in a future milestone release, which will introduce a wrapper script. Thanks again for checking out the M2 version of the Yocto Project. We really appreciate the contributions and support of the community, and we're interested in your feedback. [Less]
Posted over 12 years ago by davest
The David Stewart home was in serious want of a stereo upgrade. The old setup was from the analog days, and with the dominance of Internet, High Definition and Blue Ray, I needed a digital-enabled hub. Those who know me personally will tell you that ... [More] I tend to be somewhat, um, conservative in spending money, so I had been putting off the upgrade for as long as I could. Thankfully, my friend Saul had recently updated his setup, so I could take advantage of some of his shopping research. What I wanted was a mid-priced receiver with HDMI inputs and outputs. What I got was web-enabled. What use is a receiver with an ethernet port?  Instead of just listening to a local radio station, I can now tune my receiver to internet radio stations from all over the planet, totally for free. Or I could listen to music streamed from my Pandora, Napster or Rhapsody accounts, if I actually had one of those. While I have music pumping out, I can view photos on my Flickr stream from my latest trip or flip through some of my favorites from other photographers. But hang on - my TV has Flickr built into it also. And it has Facebook and Twitter and Netflix as well. And so does my Blue Ray player. All of this may be fine (I don't actually make use of all of this overconnect on my devices) but how can device manufacturers stand to bake in these web services in the devices they build? Some of you will remember 1997 when Pointcast was the internet-enabled news service that took the world by storm. In its day, Pointcast simply offered a ticker of news headlines at the bottom of the screen. It was great, in its day. Useless now. Can you imagine how incredibly useless it would be to have a TV today with Pointcast built in? Similarly, a TV you bought this year to get the Facebookapp built in might be considered useless next year without Google Plus integration. The solution? How do you make sure the ethernet port continues to be useful? Of course, we're talking about the online update. My TV and receiver will check from time to time for a new firmware update and can be set to update automatically when a new one is available. If my device manufacturer still cares to, they can connect me with new web services in the firmware upgrade. If you are making a device, and it is based on Linux (or best of all the Yocto Project), you are lucky in this regard: The problem with a complete system update is that you want to make sure you don't erase customer data, like their favorite internet radio stations. With Linux, you are in luck, because package management systems allows you to update only the pieces which have changed. With the Yocto Project, we include all of the most popular package managers, and you can dial in the capabilities you need from very simple (ipkg) to highly robust enterprise features. Since we update Yocto with the most relevant security patches, you can be sure that if a security vulnerability is discovered in underlying Linux code that you can protect your devices through an update. Finally, you want to make sure that a device which downloads a firmware update isn't fooled into taking in and installing software infected with a virus. This is where software signing and verification services become critical. As Yocto is adopted as the upstream for commercial embedded Linux products, signing services will become available. And as silicon vendors base their BSPs on Yocto, they will bring in hardware-based security mechanisms. Now, with all of this great digital stuff, I sincerely wish my receiver had just one more analog input. [Less]
Posted almost 13 years ago by davest
We had a lot of excitement last April when we launched the 1.0 version of the Yocto Project. We celebrated a little while, and then got ourselves back to work to begin working on the next release of the Yocto Project, due in October. The Yocto ... [More] Project Advisory Board made a recommendation that we keep things simple on naming this next release. So we're calling it "version 1.1." We laid out our proposed features at the Linux Foundation Collaboration Summit with those who were interested in collaborating, and we started work on design and cutting code. This week we released our first development milestone for the 1.1 release. Just as a reminder, we have three main development milestones which serve as synch points for features. For each of these we have a development window, and then a stabilization phase and a QA pass. We don't do extensive validation of these, but we do enough to understand the level of functionality we have at each of these points in the project, to prevent surprises at the end. If you want to track our development progress, you can always look at our schedule wiki page which we keep up to date at a very close level from week to week. As I said, our M1 release came out this week, as announced by Beth Flanagan. In the M1 milestone, we have a number of features complete and demonstratable: A rebranding of many areas of the project to reflect that we derive from the "OpenEmbedded Core" upstream project. This means for example that instead of doing "bitbake poky-image-sato," you would instead build the "core-image-sato" target. We have shifted our tool chain to GCC v4.6. We try to do this early in the development cycle, to ensure that any issues have been shaken out before release. We have some of our core packages upgraded. Our license infrastructure has been upgraded to provide more consistency and quality, and our LICENSE parser has been upgraded. We have a lot more work ahead of us. I'm very excited about the progress on multi-lib and the Hob and other features which we have ahead of us, as well as the complete set of package upgrades. If you are interested in the new M1 bits and want to try them out, now would be a great time to dig into them. [Less]
Posted almost 13 years ago by jeff
We are pleased to announce the Yocto Project's first bug-fix release. This release updates the Poky build tools to 5.0.1, adds support for Fedora 14 and Ubuntu 11.04, improves the usability of BitBake's shared state feature, fixes over 60 bugs, and ... [More] updates several key manual. See the release notes for more details, including download information. Features and Updates BitBake Updates Improved usability of Shared State Package Updates Updates and patches to security Builds supported for Fedora 14 Builds supported for Ubuntu 11.04 Fixed wrong or updated SRC_URI Corrected bad MD5SUM Documentation Updates to the Poky Reference Manual Updates to the Application Development Toolkit (ADT) Manual Updates to the Kernel Architecture and Use Manual Updates to the Yocto Project Quick Start   [Less]