It is one thing to be brought into a project as a team player, where the project is managed or you are delivering a predefined piece of it. However, that is typically not the way things happen when doing work for a small business or an initial project which will result in a business launch.
The more challenging and demanding opportunities for a freelancer are those one-man top-to-tail projects: creating the whole megillah. Here is a brief look at the steps that could give the poor shlub a fighting chance.
- Initial Meeting: The client transfers his vision to you. Determine what specifically makes or breaks its success.
Output: Management Summary: Mirror the client’s vision back to him in your own words, for validation.
- Reference site(s): Ask the client to point to sites exemplifying functionality that works and functionality that doesn’t.
Output: Create a spreadsheet that will contain a row for each function, and identify that function as either a launch requirement, nice to have for launch, post-launch, or unneeded.
- Conceptual design: Using the approved spreadsheet, decide what the site will look like.
Output: Some conceptual prototype, such as wireframes, storyboard, etc.
- Functional design: The details behind the elements of the conceptual design; how front-end elements should work, as well as the back-end functionality, business rules, and the seemingly small details (being able to print receipts with a receipt printer, accepting input from card-swipers, syncing with third-party applications, etc).
Output: Functional design document.
In Drupal 7, a hook_node_access implementation could return NODE_ACCESS_IGNORE, NODE_ACCESS_ALLOW and NODE_ACCESS_DENY. If any of them returned NODE_ACCESS_DENY then access was denied. If neither did but one returned NODE_ACCESS_ALLOW then access was allowed. If neither of these values were returned by any implementation then the decision was made based on other rules but at the end of the day some code needed to grant access explicitly or access was denied. Other entities didn’t have access control.
Imagine this scenario. You add three different blocks in your footer region and the mockups call for them to be side by side. Here are 3 ways to accomplish this:Regions
Using regions, we could add and create more footer regions and call them Footer first column, Footer second column, third and forth just like in bartik theme. I personally don’t like this solution because what if we decide in the future to only have 3 columns instead of four? Then we will need to remove regions and change the css, clear the cache etc.. not ideal.CSS
Another way to do this...
Normally, I would do this video style, but I'm a wildcard people and today we write!
A new release 0.2.13 of RInside is now on CRAN. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by Rcpp.
This release works around a bug in R 3.2.0, and addressed in R 3.2.0-patched. The NEWS extract below has more details.Changes in RInside version 0.2.13 (2015-05-20)
Added workaround for a bug in R 3.2.0: by including the file RInterface.h only once we do not getting linker errors due to multiple definitions of R_running_as_main_program (which is now addressed in R-patched as well).
Small improvements to the Travis CI script.
CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.
At Drupal Camp London 2015, I spoke with Piyush Poddar, Director of Drupal Practice at Axelerant. We talked about Piyush's history in Drupal, Drupal as a business-ready solution, India's coming of age in open source culture, and how that is driving business value.
Did you have a great time at DrupalCon Los Angeles but want something to show for it?
We are happy to issue a certificate of attendance in PDF format for anyone who picked up their conference badge or signed in at a training.
Simply submit your request via our contact page with the subject "Request a Certificate of Attendance", and be sure to include the associated order number.
How would you like to present at one of the largest PHP conferences in Europe? DrupalCon Barcelona is coming, and we are actively looking for sessions for our new PHP track.
Unlike the Coding and Development track, the PHP track is all about the larger PHP community. We're not looking for Drupal-specific talks but for sessions about PHP itself (PHP 7 anyone?), about related PHP tools like Guzzle, general PHP leading practices, software architecture, and so on.
Yesterday (May 19), the Louisiana Legislature’s House Civil Law and Procedure Committee voted 10-2 to return HB707 to the calendar, effectively voting it down, at least for the current session. The bill would allow businesses to refuse, in accordance with religious beliefs, to provide goods and services on the basis of a patron’s sexuality.
Described as the protection of “the free exercise of religious beliefs and moral convictions”, were the bill to pass it would preclude the state from taking “any adverse action against a person, wholly or partially, on the basis that such person acts in accordance with a religious belief or moral conviction about the institution of marriage.”
However, hours after the committee’s vote, Louisiana Governor Bobby Jindal issued an executive order in an attempt to accomplish much of what HB707 is intended to achieve. We’re aware that at least some of the bill’s opponents doubt the executive order may create substantive law. We’re also aware that the U.S. Supreme Court may issue a ruling (before its current term ends in late June) that preempts any contradictory Louisiana law.Why We’re Talking About Louisiana
Earlier this year, we chose New Orleans as the site for DrupalCon North America 2016. Section 86-33 of New Orleans’ municipal code explicitly forbids discrimination by public businesses and stores. In much the same spirit as New Orleans’ code, we want to take this opportunity to unequivocally state that no one at any DrupalCon should be denied service, assistance, or support because of who they are or whom they love.
Community. Collaboration. Openness. These are our ethos. At our core, we’re as committed to these values being principles for how we treat each other as we are for how we do our work.
The very nature of open source means contributions can come from anyone. That means muting voices is inconsistent with our values. That means we believe inclusivity is progress. And that means it’s important we speak when our community asks questions about the risk of discrimination.
Along with logistics—such as available event space, and costs—our DrupalCon site selection process has always considered whether we’d be able to truly celebrate the diversity of the Drupal community and the spirit of the Drupal Code of Conduct. We believe, despite the bill and executive order, that we can still create a safe, diverse, celebratory space for our community in New Orleans next year. We’re happy to bring the diversity of DrupalCon to New Orleans, and we’re confident it’ll be a fantastic event.Talk To Us
We want to hear about your experiences at DrupalCon New Orleans—any and all of them. Tell us your opinions, voice your perspectives, and share what you see. In the meantime, comment on this post, or email us, with your questions and insights.
Normally I’m sitting at home in Iowa, rocking the boxer shorts on the couch. The Xbox controller is in arm’s reach. Or maybe I’m tearing up a single track course on my mountain bike. But this week, none of that. This week is different.
It’s DrupalCon, so you know I have to put away the games and pack up the power brick so I can join in the fun. I ran through this quick Q&A about my plan for DrupalCon with Promet's marketing team to help understand my goals for this year's big show.
- restructuring website as 21st century style and drop deprecated info
- automate test integration to infrastructure: piuparts & ci
- more test for packages: adopt autopkgtest
- "go/no-go vote" for migration to next release candidate (e.g. bohdi in Fedora)
- more comfortable collab-development (see GitHub's pull request style, not mail-centric)
While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, I’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.The general deployment workflow
Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let me sum up the development activity of the different branches.
This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.
The stage branch is where code that’s about to be release (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.
The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.
Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)Where to commit Drupal updates in the development workflow?
To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).
If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.
Low (<=1 month):
- Bug fix updates - Feature updates
These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.
Medium (<5 days):
- Security updates that are no critical and not highly critical
These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.
High (<4 hours):
- Critical and highly critical security updates
For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!Requirements for automation
If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:
- Code deployment with GIT
- Trigger the update of an instance by URL using e.g. Travis.ci, Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.
- Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
- Automated tests reduce the time you spend on quality assurance
Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.
For those of you interested in Drop Guard to automate the process as described in this blog post, please sign up for the free trial period so you can test all its features – for free – and get a personal on-boarding.
This morning, I pushed out version 2.11.17 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This is a minor release. It merges conditional support for the OpenBSD MSR device (Marc Ballmer, Matthieu Herrb), fixes a condition that prevents compiling on some embedded platforms (Brian A. Lloyd) and upgrades the code for X server 1.17 compatibility (Maarten Lankhorst).
- toggle COM2 into DDC probing mode during driver initialization
- reset the DAC chip when exiting X and returning to vcons
- fix a rendering corner case with Libre Office
‘Love thy neighbor as thyself’, words which astoundingly occur already in the Old Testament.
One can love one’s neighbor less than one loves oneself; one is then the egoist, the racketeer, the capitalist, the bourgeois. and although one may accumulate money and power one does not of necessity have a joyful heart, and the best and most attractive pleasures of the soul are blocked.
Or one can love one’s neighbor more than oneself—then one is a poor devil, full of inferiority complexes, with a longing to love everything and still full of hate and torment towards oneself, living in a hell of which one lays the fire every day anew.
But the equilibrium of love, the capacity to love without being indebted to anyone, is the love of oneself which is not taken away from any other, this love of one’s neighbor which does no harm to the self.
I always have a hard time finding this quote on the Internet. Let's fix that.
I wrote well over one year ago about Earthlings. It really did have some impact on my life. Nowadays I try to avoid animal products where possible, especially for my food. And in the context of vegan information that I tracked I stumbled upon a great band from Germany: Berge. They recently started a deal with their record label which says that if they receive one million clicks within the next two weeks on their song 10.000 Tränen their record label is going to donate 10.000,- euros to a German animal rights organization. Reason enough for me to share this band with you! :)
- 10.000 Tränen: This is the song that needs the views. It's a nice tune and great lyrics to think about. Even though its in German it got English subtitles. :)
- Schauen was passiert: In the light of 10.000 Tränen it was hard for me to select other songs, but this one sounds nice. "Let's see what happens". :)
- Meer aus Farben: I love colors. And I hate the fact that most conference shirts are black only. Or that it seems to be impossible to find colorful cloths and shoes for tall women.
Like always, enjoy!
Jim Birch: Using Drupal's Environment Indicator to help visually manage Dev, Stage, and Production Servers
There are days that I work on half a dozen different websites. I'm sure some of you are in the same boat. We make client edits and change requests with rapid effieciency. We work locally, push to staging, test and review, then push to the live server and repeat. I would be remiss in saying that I never made a change on the live or staging site accidentally.
The Drupal Environment Indicator module allows you to name, color, and configure a multitude of visual queues for each of your different servers, or other variables, like Git branch or path. It is very easy to install, and can integrate with Toolbar, Admin Menu, and Mobile Friendly Navigation Toolbar for no additional screen space.
Once installed, set the permissions of the roles you want to give permission to see the indicator. You can adjust the general settings at /admin/config/development/environment-indicator/settings
While you can create different indicators inside the admin UI, I prefer to set these in the settings.php files on the various servers so they are not overidden when we move databases back from Production back to Staging and Dev.
Modules Unraveled: 135 Writing the Book Drupal 8 Configuration Management with Anja Schirwinski and Stefan Borchert - Modules Unraveled Podcast
- What’s it like writing a book for a piece of software that isn’t even officially released yet?
- How long did the writing process take?
- Packt publishing sent us a proposal to write this book in December of 2013. We got started quickly, sending them an outline of the chapters and an estimated page count in the same month. The original estimated page count was 150, it turned out to be around 120. We received a pretty strict time line, having to finish a chapter every two weeks, starting in December of 2013.
- We managed to finish most chapters in two weeks, but some of the longer ones took a little longer since we also started one of our biggest projects we had had until then, also in January. That was pretty tough because that project took up way more than a regular full time job, so we ended up having to write all of the chapters late at night and on the weekends. In May, all of our chapters then went to the editors and we didn’t hear back from the publisher for a really long time.
- We also told them that we will have to rewrite a lot of the chapters since there was so much work in progress with the Configuration Management Initiative and they were changing a lot about how it worked, like going from the file based default to the database default. I think it was in January of 2015 when chapters came back with some feedback and we started rewriting every chapter, which was pretty painful at the time. We were able to update some of the documentation at drupal.org with the changes we found. It felt good to contribution at least a small part, when with our project and the book we had no time left to contribute code to Drupal 8 like we usually do.
- We spent around 40 days on the book between the two of us.
- In December, Packt asked the first publisher to review the book. We had recommended them one of our team members at undpaul, Tom, who has a similar amount of Drupal knowledge as Stefan. We really wanted to have someone from CMI to review the book, like Greg Dunlap. They had turned down reviewing the book after the first chapters were written, because too much would still change. Then after the changes went in we kept recommending Greg but I never heard anything back, maybe he was busy or they didn’t bother to ask. At the beginning of this year they told us the book was planned to be published by March. We recommended waiting because we didn’t expect a release candidate before the European Drupalcon and we would have rather had someone like Greg take the time to review, but Packt had another opinion :) Since most of CMI changes were finished, we didn’t feel too uncomfortable about the time of publishing, and it was also kind of nice to finally be done with this thing :) So it took a little over a year from start to finish. It was published on March 24th.
- Do you expect to need to rewrite anything between now and when 8.0 is released?
- What do you cover in the book?
- We start of with a basic introduction to what Configuration Management in Drupal means, because it is a thing in Software development in general, that doesn’t usually refer to what it is in Drupal, where it basically just means that configuration is saved in files which makes deployment easier. In the first chapters, we make sure the reader understands what Configuration Management means and why version control is so important. We mention some best practices and then show how to use it for non-coders as well, since there’s a nice backend non-technical folks can use, even if you don’t use version control (which of course we don’t recommend). We also have a part that describes how managing configuration works in Drupal 7 (Features!) and then dive into code examples, explaining schema files, showing how to add configuration to a custom module, how to upgrade Drupal 7 variables to the new system and cover configuration management for multilingual sites.
- Who is the target audience of the book?
- Why did you decide to write about Configuration Management?
- We have used Features to deploy configuration changes for a very long time, I don’t recall not using it since we started the company 5 years ago. We have talked about it at several DrupalCamps and Drupal User Groups and always tried to convince everyone to use it. We were really excited about the Configuration Management Initiative and thought it was a very good fit for us.
- Before we started recording, you mentioned that there is a companion website to the book. Can you talk about what content we’ll find there, and what purpose that serves?
- Are you building any sites in D8 at Undpaul?
Eddy Petrișor: Linksys NSLU2 adventures into the NetBSD land passed through JTAG highlands - part 2 - RedBoot reverse engineering and APEX hacking
Choosing to call RedBoot from a hacked Apex
As I was saying in my previous post, in order to be able to automate the booting of the NetBSD image via TFTP I opted for using a 2nd stage bootloader (planning to flash it in the NSLU2 instead of a Linux kernel), and since Debian was already using Apex, I chose Apex, too.
The first problem I found was that the networking support in Apex was relying on an old version of the Intel NPE library which I couldn't find on Intel's site, the new version was incompatible/not building with the old build wrapper in Apex, so I was faced with 3 options:
- Fight with the availabel Intel code and try to force it to compile in Apex
- Incorporate the NPE driver from NetBSD into a rump kernel to be included in Apex instead of the original Intel code, since the NetBSD driver only needed an easily compilable binary blob
- Hack together an Apex version that simulates the typing necessary RedBoot commands to load via TFTP the netbsd image and execute it.
Option 2 looked like the best option I could have, given the situation, but my NetBSD foo was too close to 0 to even dream to endeavor on such a task. In my evaluation, this still remains the technically superior solution to the problem since is very portable, and flexible way to ensure networking works in spite of the proprietary NPE code.
But, in practice, the best option I could implement at the time was option 3. I initially planned to pre-fill from Apex the RedBoot buffer that the stored the keyboard strokes with my desired commands:
load -r -b 0x200000 -h 192.168.0.2 netbsd-nfs.bin
gSince this was the first time ever for me I was going to do less than trivial reverse engineering in order to find the addresses and signatures of interesting functions in the RedBoot code, it wasn't bad at all that I had a version of the RedBoot source code.
When stuck with reverse engineering, apply JTAG
The bad thing was that the code Linksys published as the source of the RedBoot running inside the NSLU2 was, in fact, a different code which had some significant changes around the code pieces I was mostly interested in. That in spite of the GPL terms.
But I thought that I could manage in spite of that. After all, how hard could it be to identify the 2-3 functions I was interested in and 1 buffer? Even if I only had the disassembled code from the slug, I shouldn't be that hard.
I struggled with this for about 2-3 weeks on the few occasions I had during that time, but the excitement of leaning something new kept me going. Until I got stuck somewhere between the misalignment between the published RedBoot code and the disassembled code, the state of the system at the time of dumping the contents from RAM (for purposes of disassemby), the assembly code generated by GCC for some specific C code I didn't have at all, and the particularities of ARM assembly.
What was most likely to unblock me was to actually see the code in action, so I decided attaching a JTAG dongle to the slug and do a session of in-circuit-debugging was in order.
Luckily, the pinout of the JTAG interface was already identified in the NSLU2 Linux project, so I only had to solder some wires to the specified places and a 2x20 header to be able to connect through JTAG to the board.
JTAG connections on Kinder (the NSLU2 targeting NetBSD)
After this was done I tried immediately to see if when using a JTAG debugger I could break the execution of the code on the system. The answer was sadly, no.
The chip was identified, but breaking the execution was not happening. I tried this in OpenOCD and in another proprietary debugger application I had access to, and the result was the same, breaking was not happening.
$ openocd -f interface/ftdi/olimex-arm-usb-ocd.cfg -f board/linksys_nslu2.cfgOpen On-Chip Debugger 0.8.0 (2015-04-14-09:12)Licensed under GNU GPL v2For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.htmlInfo : only one transport option; autoselect 'jtag'adapter speed: 300 kHzInfo : ixp42x.cpu: hardware has 2 breakpoints and 2 watchpoints0Info : clock speed 300 kHzInfo : JTAG tap: ixp42x.cpu tap/device found: 0x29277013 (mfg: 0x009,part: 0x9277, ver: 0x2)[..]
$ telnet localhost 4444Trying ::1...Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Open On-Chip Debugger> halttarget was in unknown state when halt was requestedin procedure 'halt'> pollbackground polling: onTAP: ixp42x.cpu (enabled)target state: unknown Looking into the documentation I found a bit of information on the XScale processors[X] which suggested that XScale processors might necessarily need the (otherwise optional) SRST signal on the JTAG inteface to be able to single step the chip.
This confused me a lot since I was sure other people had already used JTAG on the NSLU2.
The options I saw at the time were:
- my NSLU2 did have a fully working JTAG interface (either due to the missing SRST signal on the interface or maybe due to a JTAG lock on later generation NSLU-s, as was my second slug)
- nobody ever single stepped the slug using OpenOCD or other JTAG debugger, they only reflashed, and I was on totally new ground
This confused me even further because, from what I encountered on other platforms, in order to flash some device, the code responsible for programming the flash is loaded in the RAM of the target microcontroller and that code is executed on the target after a RAM buffer with the to be flashed data is preloaded via JTAG, then the operation is repeated for all flash blocks to be reprogrammed.
I was aware it was possible to program a flash chip situated on the board, outside the chip, by only playing with the chip's pads, strictly via JTAG, but I was still hoping single stepping the execution of the code in RedBoot was possible.
Guided by that hope and the possibility the newer versions of the device to be locked, I decided to add a JTAG interface to my older NSLU2, too. But this time I decided I would also add the TRST and SRST signals to the JTAG interface, just in case single stepping would work.
This mod involved even more extensive changes than the ones done on the other NSLU, but I was so frustrated by the fact I was stuck that I didn't mind poking a few holes through the case and the prospect of a connector always sticking out from the other NSLU2 which was doing some small, yet useful work in my home LAN.
It turns out NOBODY single stepped the NSLU2 After biting the bullet and soldering JTAG interface with also the TRST and the SRST signals connected as the pinout page from the NSLU2 Linux wiki suggested, I was disappointed to observe that I was not able to single step the older either, in spite of the presence of the extra signals.
I even tinkered with the reset configurations of OpenOCD, but had not success. After obtaining the same result on the proprietary debugger and digging through a presentation made by Rod back in the hay day of the project and the conversations on the NSLU2 Linux Yahoo mailing list I finally concluded:
Actually nobody single stepped the NSLU2, no matter the version of the NSLU2 or connections available on the JTAG interface!So I was back to square 1, I had to either struggle with disassembly, reevaluate my inital options, find another option or even drop entirely the idea. Since I was already committed to the project dropping entirely the idea didn't seem like the reasonable thing to do.
Since I was feeling I was really close to finish on the route I chose a while ago, was not any significantly more knowledgeable in the NetBSD code and looking at the NPE code made me feel like washing my hands, the only option I saw was to go on.
Digging a lot more through the internet, I was finally able to find another version of the RedBoot source which was modified for Intel ixp42x systems. A few checks here and there revealed this newly found code was actually almost identical to the code I had disassembled from the slug I was aiming to run NetBSD on.
Long story short, a couple of days later I had a hacked Apex that could go through the RedBoot data structures, search for available commands in RedBoot and successfully call any of the built-in RedBoot commands!
Testing with loading this modified Apex by hand in RAM via TFTP then jumping into it to see if things woked as expected revealed a few small issues which I corrected right away.
Flashing a modified RedBoot?! But why? Wasn't Apex supposed to avoid exactly that risky operation?
Since the tests when executing from RAM were successful, my custom second stage Apex bootloader for NetBSD net booting was ready to be flashed into the NSLU2.
I added two more targets in the Makefile in the code on the dedicated netbsd branch of my Apex repository to generate the images ready for flashing into the NSLU2 flash (RedBoot needs to find a Sercomm header in flash, otherwise it will crash) and the exact commands to be executed in RedBoot are also print out after generation. This way, if the command is copy-pasted, there is no risk the NSLU2 is bricked by mistake.
After some flashing and reflashing of the apex_nslu2.flash image into the NSLU2 flash, some manual testing, tweaking and modifying the default built in APEX commands, checking that the sequence of commands 'move', 'go 0x01d00000' would jump into Apex, which, in turn, would call RedBoot to transfer the netbsd-nfs.bin image from a TFTP to RAM and then execute it successfully, it was high time to check NetBSD would boot automatically after the NSLU is powered on.
It didn't. Contrary to my previous tests, no call made from Apexto the RedBoot code would return back to Apex, not even a basic execution of the 'version' command.
It turns out the default commands hardcoded into RedBoot were 'boot; exec 0x01d00000', but I had tested 'boot; go 0x01d0000', which is not the same thing.
While 'go' does a plain jump at the specified address, the 'exec' command also does some preparations so it allows a jump into the Linux kernel and those preparations break some environment the RedBoot commands expect.
So the easiest solution was to change the RedBoot's built-in command and turn that 'exec' into a 'go'. But that meant this time I was actually risking to brick the NSLU, unless I
was able to reflash via JTAG the NSLU2.
(to be continued - next, changing RedBoot and bisecting through the NetBSD history)
[X] Linksys NSLU2 has an XScale IXP420 processor which is compatible at ASM level with the ARMv5TEJ instruction set
The other day I received from my Japanese teacher an interesting article by Yamazaki Masakazu 山崎正和 comparing garden styles, and in particular the attitude towards and presentation of water in Japanese and European gardens (page 1, page 2). The author’s list of achievements is long, various professorships, dramatist, literature critique, recognized as Person of Cultural Merit, just to name a view. I was looking forward to an interesting and high quality article!
The article itself introduces the reader to 鹿おどし Shishiodoshi, one of the standard ingredients of a Japanese garden: It is a device where water drips into a bamboo tube that is also a seesaw. At some point the water in the bamboo tube makes the seesaw switch over and the water pours out, after which the seesaw returns to the original position and a new cycle begins.
The author describes his feelings and thoughts about the shishiodoshi, in particular connects human life (stress and relieve, cycles), the flow of time, and some other concepts with the shishiodoshi. Up to here it is a wonderful article providing interesting insights into the way the author thinks. Unfortunately, then the author tries to underline his ideas by comparing the Japanese shishiodoshi with European style water fountains, describing the former with all favorable properties and full of deep meaning, while the latter is qualified as beautiful and nice, but bare of any deeper meaning.
I don’t go into details that the whole comparison is anyway a bad one, as he is comparing Baroque style fountains, a very limited period, and furthermore ignores the fact that water fountains are not genuinely European (isn’t there one in the Kenrokuen, one of the three most famous gardens in Japan!?), nor does he consider any other “water-installation” that might be available. What really destroys the in principle very nice article is the tone:
The general tone of the article then can be summarized into: “The shishiodoshi is rich on meaning, connects to the life of humans, instigates philosophical reflections, represents nature, the flow of time etc. The water fountain is beautiful and gorgeous, but that is all.”
I don’t think that this separation, or this negative undertone, was created on purpose by the author. A person of his stature is supposedly above this level of primitive comparison. I believe that it is nothing else but a consequence of upbringing and the general attitude that permeates the whole society with this feeling of separateness.Us and They
Repeatedly providing sentences like “Japanese people and Western people have different tastes..” (日本人は西洋人と違った独特の好みを持っていたのである). About 10 times in this short article expressions like “Japanese” and “Westerner” appear, leaving the reader with a bitter taste of an author that considers first the Japanese a people (what about Ainu, Ryukyu, etc?), and second that the Japanese are exclusive in the sense that they are set apart from the rest of the world in their way of thinking, living, being.
What puzzles me is that this is not only a singular opinion, but a very general straight in the Japanese media, TV, radio, newspaper, books. Everyone considers “Japan” and “Japanese” as something that is fundamentally and profoundly different from everyone else in the world.
There is “We – the Japanese” (and that doesn’t mean nationality of passport, but blood line!), and there are “They – the Rest” or, as the way of writing and and description on many occasion suggestions, “They – the Barbarians”.
A short anecdote will underly this: One of the favorite TV talk show / pseudo-documentary style is about Japanese living abroad. That day a lady married in Paris was interviewed. What followed was a guided tour through Paris showing: Dirt in the gutter, street cleaning cars, waste disposal places. Yes, that was all. Just about the “dirt”. Of course, at length the (unfortunately only apparent) cleanliness of Japanese cities and neighborhoods are mentioned and shown to remind everyone how wonderful Japan is and how dirty the Barbarians. I don’t want to say that I consider Japan more dirty than most other countries – just the visible part is clean, the moment you step a bit aside and around the corner, there are the worst trash just thrown away without consideration. Anyway.
To return to the topic of “Us and They” – I consider us all humans, first and foremost, and nationality, birthplace, and all that are just by chance. I do NOT reject cultural differences, they are here, of course. But cultural differences are one thing, separating one self and one’s perceived people from the rest of the world is another.Conclusion
I repeat, I don’t think that the author had any ill intentions, but it would have been nicer if the article wouldn’t make such a stark distinction. He could have written about Shishiodoshi and water fountains without using the “Us – They” categorization. He could have compared other water installations, could have discussed the long tradition of small ponds in European gardens, just to name a few things. But the author choose to highlight differences instead of commonalities.
It is the “Us against Them” feeling that often makes life in Japan for a foreigner difficult. Japanese are not special, Austrians, too, are not special, nor are Americans, Russians, Tibetans, or any other nationality. No nationality is special, we are all humans. Maybe at some point this will arrive also in the Japanese society and thinking.