fidzu : smartphone

Posted by Jamal Eason, Product Manager, Android

After nearly six months of development, Android Studio 3.4 is ready to download today on the stable release channel. This is a milestone release of the Project Marble effort from the Android Studio team. Project Marble is our focus on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. On top of many performance improvements and bug fixes we made in Android Studio 3.4, we are excited to release a small but focused set of new features that address core developer workflows for app building & resource management.

Part of the effort of Project Marble is to address user facing issues in core features in the IDE. At the top of the list of issues for Android Studio 3.4 is an updated Project Structure Dialog (PSD) which is a revamped user interface to manage dependencies in your app project Gradle build files. In another build-related change, R8 replaces Proguard as the default code shrinker and obfuscator. To aid app design, we incorporated your feedback to create a new app resource management tool to bulk import, preview, and manage resources for your project. Lastly, we are shipping an updated Android Emulator that takes less system resources, and also supports the Android Q Beta. Overall, these features are designed to make you more productive in your day-to-day app development workflow.

Alongside the stable release of Android Studio 3.4, we recently published in-depth blogs on how we are investigating & fixing a range of issues under the auspices of Project Marble. You should check them out as you download the latest update to Android Studio:

• Project Marble: Apply Changes
• Improving build speed in Android Studio
• Android Emulator: Project Marble Improvements
• Android Studio Project Marble: Lint Performance

The development work for Project Marble is still on-going, but Android Studio 3.4 incorporates productivity features and over 300 bug & stability enhancements that you do not want to miss. Watch and read below for some of the notable changes and enhancements that you will find in Android Studio 3.4.

Develop

• Resource Manager - We have heard from you that asset management and navigation can be clunky and tedious in Android Studio, especially as your app grows in complexity. The resource manager is a new tool to visualize the drawables, colors, and layouts across your app project in a consolidated view. In addition to visualization, the panel supports drag & drop bulk asset import, and, by popular request, bulk SVG to VectorDrawable conversion. These accelerators will hopefully help manage assets you get from a design team, or simply help you have a more organized view of project assets. Learn more.

Resource Manager

• Import Intentions - As you work with new Jetpack and Firebase libraries, Android Studio 3.4 will recognize common classes in these libraries and suggest, via code intentions, adding the required import statement and library dependency to your Gradle project files. This optimization can be a time saver since it keeps you in the context of your code. Moreover, since Jetpack libraries are modularized, Android Studio can find the exact library or minimum set of libraries required to use a new Jetpack class.

Jetpack Import Intentions

• Layout Editor Properties Panel - To improve product refinement and polish we refreshed the Layout Editor Properties panel. Now we just have one single pane, with collapsible sections for properties. Additionally, errors and warnings have their own highlight color, we have a resource binding control for each property, and we have an updated color picker.

Layout Editor Properties Panel

• IntelliJ Platform Update - Android Studio 3.4 includes Intellij 2018.3.4. This update has a wide range of improvements from support for multi-line TODOs to an updated search everywhere feature. Learn more.

Build

• Project Structure Dialog - A long standing request from many developers is to have a user interface front end to manage Gradle project files. We have more plans for this area, but Android Studio 3.4 includes the next phase of improvement in the Product Structure Dialog (PSD). The new PSD allows you to see and add dependencies to your project at a module level. Additionally, the new PSD displays build variables, suggestions to improve your build file configuration, and more! Although the latest Gradle plugin v3.4 also has improvements, you do not have to upgrade your Gradle plugin version number to take advantage of the new PSD. Learn more.

Project Structure Dialogue

• R8 by Default - Almost two years ago we previewed R8 as the replacement for Proguard. R8 code shrinking helps reduce the size of your APK by getting rid of unused code and resources as well as making your actual code take less space. Additionally, in comparison to Proguard, R8 combines shrinking, desugaring and dexing operations into one step, which ends up to be a more efficient approach for Android apps. After additional validation and testing last year, R8 is now the default code shinker for new projects created with Android Studio 3.4 and for projects using Android Gradle plugin 3.4 and higher. Learn more.

Test

• Android Emulator Skin updates & Android Q Beta Emulator System Image - Inside of Android Studio 3.4 we released the latest Google Pixel 3 & Google Pixel 3 XL device skins. Also with this release, you can also download Android Q Beta emulator system images for app testing on Android Q. Please note that we do recommend running the canary version of Android Studio and the emulator to get the latest compatibility changes during the Android Q Beta program.

Android Emulator - Pixel 3 XL Emulator Skin

To recap, Android Studio 3.4 includes these new enhancements & features:

Develop

• Resource Manager
• Import Intentions
• Layout Editor Properties Panel
• IntelliJ 2018.3.4 Platform Update

Build

• Project Structure Dialog
• R8 by Default

Test

• Emulator Device Skins
• Android Q Beta Emulator System Image Support

Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.

Getting Started

Download

Download the latest version of Android Studio 3.4 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v28.0.22 downloaded via the Android Studio SDK Manager.

We appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

17 Apr 2019 6:19pm GMT

Posted by Anuj Gulati, Developer Marketing Manager and Sami Kizilbash, Developer Relations Program Manager

Last year we announced the Indie Games Accelerator, a special edition of Launchpad Accelerator, to help top indie game developers from emerging markets achieve their full potential on Google Play. Our team of program mentors had an amazing time coaching some of the best gaming talent from India, Pakistan, and Southeast Asia. We're very encouraged by the positive feedback we received for the program and are excited to bring it back in 2019.

Applications for the class of 2019 are now open, and we're happy to announce that we are expanding the program to developers from select countries* in Asia, Middle East, Africa, and Latin America.

Successful participants will be invited to attend two gaming bootcamps, all-expenses-paid at the Google Asia-Pacific office in Singapore, where they will receive personalized mentorship from Google teams and industry experts. Additional benefits include Google hardware, invites to exclusive Google and industry events and more.

Find out more about the program and apply to be a part of it.

* The competition is open to developers from the following countries: Bangladesh, Brunei, Cambodia, India, Indonesia, Laos, Malaysia, Myanmar, Nepal, Pakistan, Philippines, Singapore, Sri Lanka, Thailand, Vietnam, Egypt, Jordan, Kenya, Lebanon, Nigeria, South Africa, Tunisia, Turkey, Argentina, Bolivia, Brazil, Chile, Colombia, Costa Rica, Ecuador, Guatemala, Mexico, Panama, Paraguay, Peru, Uruguay and Venezuela.

How useful did you find this blog post?

★ ★ ★ ★ ★

17 Apr 2019 6:00am GMT

Posted by Sameer Samat, VP of Product Management, Android & Google Play

Thank you for all the feedback about updates we've been making to Android APIs and Play policies. We've heard your requests for improvement as well as some frustration. We want to explain how and why we're making these changes, and how we are using your feedback to improve the way we roll out these updates and communicate with the developer community.

From the outset, we've sought to craft Android as a completely open source operating system. We've also worked hard to ensure backwards compatibility and API consistency, out of respect and a desire to make the platform as easy to use as possible. This developer-centric approach and openness have been cornerstones of Android's philosophy from the beginning. These are not changing.

But as the platform grows and evolves, each decision we make comes with trade-offs. Everyday, billions of people around the world use the apps you've built to do incredible things like connect with loved ones, manage finances or communicate with doctors. Users want more control and transparency over how their personal information is being used by applications, and expect Android, as the platform, to do more to provide that control and transparency. This responsibility to users is something we have always taken seriously, and that's why we are taking a comprehensive look at how our platform and policies reflect that commitment.

Taking a closer look at permissions

Earlier this year, we introduced Android Q Beta with dozens of features and improvements that provide users with more transparency and control, further securing their personal data. Along with the system-level changes introduced in Q, we're also reviewing and refining our Play Developer policies to further enhance user privacy. For years, we've required developers to disclose the collection and use of personal data so users can understand how their information is being used, and to only use the permissions that are really needed to deliver the features and services of the app. As part of Project Strobe, which we announced last October, we are rolling out specific guidance for each of the Android runtime permissions, and we are holding apps developed by Google to the same standard.

We started with changes to SMS and Call Log permissions late last year. To better protect sensitive user data available through these permissions, we restricted access to select use cases, such as when an app has been chosen by the user to be their default text message app. We understood that some app features using this data would no longer be allowed -- including features that many users found valuable -- and worked with you on alternatives where possible. As a result, today, the number of apps with access to this sensitive information has decreased by more than 98%. The vast majority of these were able to switch to an alternative or eliminate minor functionality.

Learning from developer feedback

While these changes are critical to help strengthen privacy protections for our users, we're sensitive that evolving the platform can lead to substantial work for developers. We have a responsibility to make sure you have the details and resources you need to understand and implement changes, and we know there is room for improvement there. For example, when we began enforcing these new SMS and Call Log policies, many of you expressed frustration about the decision making process. There were a number of common themes that we wanted to share:

• Permission declaration form. Some of you felt that the use case descriptions in our permissions declaration form were unclear and hard to complete correctly.
• Timeliness in review and appeals process. For some of you, it took too long to get answers on whether apps met policy requirements. Others felt that the process for appealing a decision was too long and cumbersome.
• Getting information from a 'real human' at Google. Some of you came away with the impression that our decisions were automated, without human involvement. And others felt that it was hard to reach a person who could help provide details about our policy decisions and about new use cases proposed by developers.

In response, we are improving and clarifying the process, including:

• More detailed communication. We are revising the emails we send for policy rejections and appeals to better explain with more details, including why a decision was made, how you can modify your app to comply, and how to appeal.
• Evaluations and appeals. We will include appeal instructions in all enforcement emails and the appeal form with details can also be found in our Help Center. We will also be reviewing and improving our appeals process.
• Growing the team. Humans, not bots, already review every sensitive decision but we are improving our communication so responses are more personalized -- and we are expanding our team to help accelerate the appeals process.

Evaluating developer accounts

We have also heard concerns from some developers whose accounts have been blocked from distributing apps through Google Play. While the vast majority of developers on Android are well-meaning, some accounts are suspended for serious, repeated violation of policies that protect our shared users. Bad-faith developers often try to get around this by opening new accounts or using other developers' existing accounts to publish unsafe apps. While we strive for openness wherever possible, in order to prevent bad-faith developers from gaming our systems and putting our users at risk in the process, we can't always share the reasons we've concluded that one account is related to another.

While 99%+ of these suspension decisions are correct, we are also very sensitive to how impactful it can be if your account has been disabled in error. You can immediately appeal any enforcement, and each appeal is carefully reviewed by a person on our team. During the appeals process, we will reinstate your account if we discover that an error has been made.

Separately, we will soon be taking more time (days, not weeks) to review apps by developers that don't yet have a track record with us. This will allow us to do more thorough checks before approving apps to go live in the store and will help us make even fewer inaccurate decisions on developer accounts.

Thank you for your ongoing partnership and for continuing to make Android an incredibly helpful platform for billions of people around the world.

How useful did you find this blog post?

★ ★ ★ ★ ★

15 Apr 2019 6:16pm GMT

0 0

13 Mar 2019 4:07pm GMT

This is the first report about Igalia's activities around Computer Graphics, specifically 3D graphics and, in particular, the Mesa3D Graphics Library (Mesa), focusing on the year 2018.

GL_ARB_gl_spirv and GL_ARB_spirv_extensions

GL_ARB_gl_spirv is an OpenGL extension whose purpose is to enable an OpenGL program to consume SPIR-V shaders. In the case of GL_ARB_spirv_extensions, it provides a mechanism by which an OpenGL implementation would be able to announce which particular SPIR-V extensions it supports, which is a nice complement to GL_ARB_gl_spirv.

As both extensions, GL_ARB_gl_spirv and GL_ARB_spirv_extensions, are core functionality in OpenGL 4.6, the drivers need to provide them in order to be compliant with that version.

Although Igalia picked up the already started implementation of these extensions in Mesa back in 2017, 2018 is a year in which we put a big deal of work to provide the needed push to have all the remaining bits in place. Much of this effort provides general support to all the drivers under the Mesa umbrella but, in particular, Igalia implemented the backend code for Intel's i965 driver (gen7+). Assuming that the review process for the remaining patches goes without important bumps, it is expected that the whole implementation will land in Mesa during the beginning of 2019.

Throughout the year, Alejandro Piñeiro gave status updates of the ongoing work through his talks at FOSDEM and XDC 2018. This is a video of the latter:

ETC2/EAC

The ETC and EAC formats are lossy compressed texture formats used mostly in embedded devices. OpenGL implementations of the versions 4.3 and upwards, and OpenGL/ES implementations of the versions 3.0 and upwards must support them in order to be conformant with the standard.

Most modern GPUs are able to work directly with the ETC2/EAC formats. Implementations for older GPUs that don't have that support but want to be conformant with the latest versions of the specs need to provide that functionality through the software parts of the driver.

During 2018, Igalia implemented the missing bits to support GL_OES_copy_image in Intel's i965 for gen7+, while gen8+ was already complying through its HW support. As we were writing this entry, the work has finally landed.

VK_KHR_16bit_storage

Igalia finished the work to provide support for the Vulkan extension VK_KHR_16bit_storage into Intel's Anvil driver.

This extension allows the use of 16-bit types (half floats, 16-bit ints, and 16-bit uints) in push constant blocks, and buffers (shader storage buffer objects). This feature can help to reduce the memory bandwith for Uniform and Storage Buffer data accessed from the shaders and / or optimize Push Constant space, of which there are only a few bytes available, making it a precious shader resource.

shaderInt16

Igalia added Vulkan's optional feature shaderInt16 to Intel's Anvil driver. This new functionality provides the means to operate with 16-bit integers inside a shader which, ideally, would lead to better performance when you don't need a full 32-bit range. However, not all HW platforms may have native support, still needing to run in 32-bit and, hence, not benefiting from this feature. Such is the case for operations associated with integer division in the case of Intel platforms.

shaderInt16 complements the functionality provided by the VK_KHR_16bit_storage extension.

SPV_KHR_8bit_storage and VK_KHR_8bit_storage

SPV_KHR_8bit_storage is a SPIR-V extension that complements the VK_KHR_8bit_storage Vulkan extension to allow the use of 8-bit types in uniform and storage buffers, and push constant blocks. Similarly to the the VK_KHR_16bit_storage extension, this feature can help to reduce the needed memory bandwith.

Igalia implemented its support into Intel's Anvil driver.

VK_KHR_shader_float16_int8

Igalia implemented the support for VK_KHR_shader_float16_int8 into Intel's Anvil driver. This is an extension that enables Vulkan to consume SPIR-V shaders that use Float16 and Int8 types in arithmetic operations. It extends the functionality included with VK_KHR_16bit_storage and VK_KHR_8bit_storage.

In theory, applications that do not need the range and precision of regular 32-bit floating point and integers, can use these new types to improve performance. Additionally, its implementation is mostly API agnostic, so most of the work we did should also help to have a proper mediump implementation for GLSL ES shaders in the future.

The review process for the implementation is still ongoing and is on its way to land in Mesa.

VK_KHR_shader_float_controls

VK_KHR_shader_float_controls is a Vulkan extension which allows applications to query and override the implementation's default floating point behavior for rounding modes, denormals, signed zero and infinity.

Igalia has coded its support into Intel's Anvil driver and it is currently under review before being merged into Mesa.

VkRunner

VkRunner is a Vulkan shader tester based on shader_runner in Piglit. Its goal is to make it feasible to test scripts as similar as possible to Piglit's shader_test format.

Igalia initially created VkRunner as a tool to get more test coverage during the implementation of GL_ARB_gl_spirv. Soon, it was clear that it was useful way beyond the implementation of this specific extension but as a generic way of testing SPIR-V shaders.

Since then, VkRunner has been enabled as an external dependency to run new tests added to the Piglit and VK-GL-CTS suites.

Neil Roberts introduced VkRunner at XDC 2018. This is his talk:

freedreno

During 2018, Igalia has also started contributing to the freedreno Mesa driver for Qualcomm GPUs. Among the work done, we have tackled multiple bugs identified through the usual testing suites used in the graphic drivers development: Piglit and VK-GL-CTS.

Khronos Conformance

The Khronos conformance program is intended to ensure that products that implement Khronos standards (such as OpenGL or Vulkan drivers) do what they are supposed to do and they do it consistently across implementations from the same or different vendors.

This is achieved by producing an extensive test suite, the Conformance Test Suite (VK-GL-CTS or CTS for short), which aims to verify that the semantics of the standard are properly implemented by as many vendors as possible.

In 2018, Igalia has continued its work ensuring that the Intel Mesa drivers for both Vulkan and OpenGL are conformant. This work included reviewing and testing patches submitted for inclusion in VK-GL-CTS and continuously checking that the drivers passed the tests. When failures were encountered we provided patches to correct the problem either in the tests or in the drivers, depending on the outcome of our analysis or, even, brought a discussion forward when the source of the problem was incomplete, ambiguous or incorrect spec language.

The most important result out of this significant dedication has been successfully passing conformance applications.

OpenGL 4.6

Igalia helped making Intel's i965 driver conformant with OpenGL 4.6 since day zero. This was a significant achievement since, besides Intel Mesa, only nVIDIA managed to do this too.

Igalia specifically contributed to achieve the OpenGL 4.6 milestone providing the GL_ARB_gl_spirv implementation.

Vulkan 1.1

Igalia also helped to make Intel's Anvil driver conformant with Vulkan 1.1 since day zero, too.

Igalia specifically contributed to achieve the Vulkan 1.1 milestone providing the VK_KHR_16bit_storage implementation.

Mesa Releases

Igalia continued the work that was already carrying on in Mesa's Release Team throughout 2018. This effort involved a continuous dedication to track the general status of Mesa against the usual test suites and benchmarks but also to react quickly upon detected regressions, specially coordinating with the Mesa developers and the distribution packagers.

The work was obviously visible by releasing multiple bugfix releases as well as doing the branching and creating a feature release.

CI

Continuous Integration is a must in any serious SW project. In the case of API implementations it is even critical since there are many important variables that need to be controlled to avoid regressions and track the progress when including new features: agnostic tests that can be used by different implementations, different OS platforms, CPU architectures and, of course, different GPU architectures and generations.

Igalia has kept a sustained effort to keep Mesa (and Piglit) CI integrations in good health with an eye on the reported regressions to act immediately upon them. This has been a key tool for our work around Mesa releases and the experience allowed us to push the initial proposal for a new CI integration when the FreeDesktop projects decided to start its migration to GitLab.

This work, along with the one done with the Mesa releases, lead to a shared presentation, given by Juan Antonio Suárez during XDC 2018. This is the video of the talk:

XDC 2018

2018 was the year that saw A Coruña hosting the X.Org Developer's Conference (XDC) and Igalia as Platinum Sponsor.

The conference was organized by GPUL (Galician Linux User and Developer Group) together with University of A Coruña, Igalia and, of course, the X.Org Foundation.

Since A Coruña is the town in which the company originated and where we have our headquarters, Igalia had a key role in the organization, which was greatly benefited by our vast experience running events. Moreover, several Igalians joined the conference crew and, as mentioned above, we delivered talks around GL_ARB_gl_spirv, VkRunner, and Mesa releases and CI testing.

The feedback from the attendees was very rewarding and we believe the conference was a great event. Here you can see the Closing Session speech given by Samuel Iglesias:

Other activities

Conferences

As usual, Igalia was present in many graphics related conferences during the year:

• FOSDEM, in Brussels.
• GDC, in San Francisco.
• SIGGRAPH, in Vancouver.
• And obviously, XDC, in A Coruña.

New Igalians in the team

Igalia's graphics team kept growing. Two new developers joined us in 2018:

• Hyunjun Ko is an experienced Igalian with a strong background in multimedia. Specifically, GStreamer and Intel's VAAPI. He is now contributing his impressive expertise into our Graphics team.
• Arcady Goldmints-Orlov is the latest addition to the team. His previous expertise as a graphics developer around the nVIDIA GPUs fits perfectly for the kind of work we are pushing currently in Igalia.

Conclusion

Thank you for reading this blog post and we look forward to more work on graphics in 2019!

0 0

25 Feb 2019 2:50pm GMT

0 0

30 Jan 2019 8:21pm GMT

A small brain dump of topics that currently fascinate me. These are mostly pointers and maybe it is interesting to follow it.

Books/Reading:

My kobo ebook reader has the Site Reliability Engineering book and I am now mostly done. It is kind of a revelation and explains my interest to write code but also to operate infrastructure (like struggling with ruby, rmagick, nginx…). I am interested in backends since… well ever. The first time I noticed it when we talked about Kolab at LinuxTag and I was more interested in the backend than the KDE client. At sysmocom we built an IoT product and the backend was quite some fun, especially the scale of one instance and many devices/users, capacity planning and disk commissioning, lossless upgrades.

It can be seen in my non FOSS SS7 map work on traffic masquerading and transparent rewriting. It is also clear to see which part of engineering is needed for scale (instead of just installing and restarting servers).

Lang VM design

One technology that made Java fast (Hotspot) and has seen its way into JavaScript is dynamic optimization. Most Just in Time Compilers start with generating native code per method, either directly or after the first couple of calls when the methods size is significant enough. The VM records which call paths are hot, which types are used and then can generate optimized code (e.g. specialized for integers, remove type checks). A technique pioneered at Sun for the "Self" language (and then implemented for Strongtalk and then brought to Java) was "adaptive optimization and deoptimization" and was the Phd topic of Urs Hoelzle (Google's VP of Engineering). One of the key aspects is inlining across method boundaries as this removes method look-up, call stack handling and opens the way for code optimization across method boundaries (at the cost of RAM usage).

In OpenJDK, V8 and JavaScriptCore this adaptive optimization is typically implemented in C++ and requires quite some code. The code is complicated as it needs to optimize but also need to return to a basic function (deoptimize, e.g. if a method changed or the types passed don't match anymore), e.g. in the middle of a for loop with tons of inlined code (think of Array.map being inlined but then need to be de-inlined). A nice and long blog post of JSC can be found here describing the On Stack Replacement (OSR).

Long introduction and now to the new thing. In the OpensmalltalkVM a new approach called Sista has been picked and I find it is genius. Like with many problems the point of view and approach really matters. Instead of writing a lot of code in the VM the optimizer runs next to the application code. The key parts seem to be:

• Using branches taken/not-taken as indicator how hot a path is. The overhead of counting these seem to be better than counting method calls/instructions/loops.
• Using the Inline Caches for type information on call sites (is that mono-, poly- or megamorphic?)
• Optimize from one set of Bytecode to another set of Bytecode.

The revelation is the last part. By just optimizing from bytecode to bytecode the VM remains in charge of creating and managing machine code. The next part is that tooling in the higher language is better or at least the roundtrip is more quick (edit code and just compile the new method instead of running make, c++, ld). The productivity thanks to the abstraction and tooling is likely higher.

As last part the OSR is easier as well. In Smalltalk thisContext (the current stack frame, activation record) is an object as well. At the right point (when the JIT has either written back variables from register to the stack or at least knows where the value is) one can just manipulate thisContext, create and link news ones and then resume execution without all the magic in other VMs.

Go, Go and escape analysis

Ken Thompson and Robert Pike are well known persons and their Go programming language is a very interesting system programming language. Like with all new languages I try to get real world experience with the language, the tooling and which kind of problems can be solved with it. I have debugged and patched some bigger projects and written two small applications with it.

There is plenty I like. The escape analysis of the compiler is fun (especially now that I know it was translated from the Plan9 C compiler from C to Go), the concurrency model is good (though allowing shared state), the module system makes sense (but makes forking harder than necessary), being able to cross compile to any target from any system.

Knowing a bit of Erlang (and continuing to read the Phd Thesis of Joe Armstrong) and being a heavy Smalltalk user there are plenty of things missing. It starts with vague runtime error messages (e.g. panicslice not having parameters) and goes to runtime and post-runtime inspection. In Smalltalk thanks to the abstraction a lot of hard things are easy and I would have wished for some of them to be in Go. Serialize all unrecovered panics? Debugging someone else's code seems like pre 1980…

So for many developers Go is a big improvement but for some people with a wider view it might look like a lost opportunity. But that can only be felt by developers that have experienced higher abstraction and productivity.

Unsupervised machine learning

but that is for another dump…

25 Sep 2017 10:11am GMT

02 Sep 2017 10:00pm GMT

01 Sep 2017 10:00pm GMT

Shopping for 3D TV (again), few findings:

• There are no non-LED 3D TVs for sale in this part of world anymore (in particular, my older favorite, LE40C750 is no longer available)
• Samsung D6xxx series (the cheapest) were caught red-handed not providing FullHD resolution in 3D: via Samygo. (Note from myself: Samsung was caught because lots of people actually buy their stuff, what one can think about other vendors?)
• LG goes out of line of vendors with 3D shutter glasses technology with their FPR ("Cinema 3D" in marketing speak) technology. It uses passive (no power needed) polarized glasses, like RealD cimenas. Announced April (on these longitudes), already in local shops at not-so-indecent prices. FPR is Film Patterned Retarder, and I hope the last word is spelled right, because I have high hopes for this tech. It shares the same issue as Samsung D6xxx: there won't FullHD here for sure, but at least it's official and there're other benefits.

12 Nov 2011 6:55pm GMT

I finally going to get Arduino, and while I'm choosing flavor and waiting for it, I can't help but disassembling all devices I have at home, each time speaking: "This must have Arduino inside!" (meaning of course that I expect it to be based on general-purpose MCU). Gosh, I usually get "blob chip" (uncased chip with blob of epoxy on top).

Well, I finally had my expectations fulfilled - Luxeon SP-1 voltage stabilizer/cutter features ATMEGA48V-10PU (Flash: 4k, EEPROM: 256, RAM:512). Not only that, it is installed in DIP socket! Buy from Luxeon, they're hacker-friendly ;-).

I bought the device actually for a wattmeter it features (which fact is hard to figure out from common specs found in the shops, I accidentally read somebody mentioning it on a forum). The wattmeter is of course not bright - for a lamp rated 100W it shows 88W, and for more powerful equipment (like perforator) understates wattage even more (maybe it's difference between real and apparent power factor).

Still, for $17 you get Arudino-alike with voltage/current sensor and hacking possibility. Woot!

BOM:
High-power board:

• Relay: Coil: 24VDC, 5A/240VAC
• 7805
• Coil transformer LR-019B

MCU board:

• ATMEGA48V-10PU
• 2 buttons
• 2 LEDs (red & green)
• 3-digit 7-segment LED indicator

12 Nov 2011 5:58pm GMT

Kindle:

• Amazon Kindle official GPL source code
• Kindle keyboard shortcuts and other reference
• Latest jailbreak appears to be one from NiLuJe (forum). It's known to work with firmware 3.3. Hacks/updates should be copied to Kindle USB drive root.
• SirAlex's page
• Intro for writing kindlets
  

Linux kernel module tricks:

• How to bind Linux driver to device whose IDs it doesn't know (yet), without recompiling
• Building a kernel module separately
• (build module from a kernel source tarball using currently installed kernel config)

10 Nov 2011 3:21pm GMT

In Debian Unstable the transition to Gnome 3 is taking place; when Gnome 3.0 firstly came out some unnamed geeky users complained loudly about the design decisions of the development team to push strongly towards gnome-shell as a new default UI; gnome-shell was designed focusing on usability (usability is a metric relative to a certain target audience BTW) and simplicity, hiding a lot of details from the users. Obviously you can never make everyone happy so some of us simply happened to be "out of target": you know us computer people (*cough cough*), we like to be in charge and control The Machine... I must admit I still don't have a definitive opinion about the gnome-shell concept, for now I just know that it does not suit me; I am going to try it eventually, maybe I'll get used to it, but in the mean time I need my desktop back just like I shaped it through the years; can this be done without loosing all the good Gnome technologies (Empathy over all of them)?

To be completely fair I have to say that there is little to complain about with Gnome developers, we can still get our good old GNOME desktop fully back by using the fall-back mode based on gnome-panel and live happily ever after, let's take a look at how this can be accomplished.

NOTE: GNOME people state that the fall-back mode is meant for systems with older graphic cards which cannot run gnome-shell, however it can very well be seen as a good opportunity for those who do not want to run gnome-shell just yet.

Getting back to the topic: some minor touches are needed to make the panel look more like what we are used to, maybe some of these settings could even become default for fall-back mode, we'll see.

First, enable fall-back mode (on Debian there is a dedicated session you can choose from the Log-in Manager for that) and change some desktop settings, in a terminal type:

$ gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
$ gsettings set org.gnome.desktop.interface 'menus-have-icons' true
$ gsettings set org.gnome.desktop.interface 'buttons-have-icons' true
$ gsettings set org.gnome.desktop.background 'show-desktop-icons' true

gnome-tweak-tool can be used for some of these settings like shown in the attached images.

Then rearrange the applets on the panel as you please (use Alt-RightClick to access the panel properties), and fix the theming using this patch to have a light panel again (against gnome-themes-standard=3.0.2-1):

$ mkdir $HOME/.themes
$ cd $HOME/.themes
$ cp -r /usr/share/themes/Adwaita Adwaita-fallback
$ cd Adwaita-fallback
$ patch -p1 < $HOME/adwaita-fallback-panel-theme.patch
$ gsettings set org.gnome.desktop.interface 'gtk-theme' 'Adwaita-fallback'

Some final touches for the Metacity window manager and to the clock applet, and we are all set:

$ gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
$ gconftool-2 --type boolean --set /apps/metacity/general/compositing_manager true
$ gconftool-2 --type string --set /apps/panel3-applets/clock/custom_format '<span color="#333">%a %d %b</span> <b>%H:%M</b>'
$ gconftool-2 --type string --set /apps/panel3-applets/clock/format custom

Ah, in the new gnome-panel based on Gtk3 there are still some details to take care of, I hope issues like that will be addressed and that the panel will be supported for quite some time.

19 Oct 2011 9:37pm GMT

After letting us wait for a bit longer than scheduled (13 days), the hospital initiated the contractions. For the first couple of hours, everything went just perfect, but then the little one got stuck on the way and we had to resort to a cesarean section. Lara Marie Lauer was born 8th of June at 04:41 (AM) with 3460 gramms and 49 cm.

Mummy was still on intensive care and so they gave her to me. I can't express the feelings I had in this very moment. I'm still kind of overwhelmed every time I see her. Thanks for all of you who waited anxiously with me and those who prayed for us. The most important tasks for the near future is getting Mummy to recover and Lara Marie to become accustomed to us and the rest of the outside world.

Please bear with me if in the next time I'm not as responsive as usually

09 Jun 2011 4:06pm GMT

And now for something completely different… while we are all waiting for my baby to arrive (who was scheduled for 25th of May), she just received her first greeting card - together with a personalized bib and a towel (with integrated hood - pretty fancy!) from my good friends at #openmoko-cdevel.

Guys, seeing this card was very heartwarming - it means a lot to me that you share my anticipation, thanks a lot! And I'm 100% sure she will appreciate her gifts… now let's cross fingers it won't take much longer… waiting is the hardest part of it

Yours,

Mickey.

30 May 2011 8:54am GMT