חגיגת בת מצווה במועדון בת מצווה בשרון

צוות התחקירים שלנו עבר בלא מעט מועדונים בשנתיים האחרונות, בדק, טעם ונכח בלא מעט אירועים.
בכתבות קודמות בנושא סקרנו אירועים כדוגמת: מסיבות טבע, מסיבות במועדונים שונים במרכז ובצפון, אולמות חתונות, אולמות כנסים והרשימה עוד ארוכה.

הפעם בחרנו להביא לכם תחילתה של סקירה בנושא מועדוני בת מצווה והשבוע ביקרנו במועדוני בת מצווה באזור השרון כאשר את אחד מהם בחרנו בסופו של דבר להגיש לכם ולהמליץ עליו. שמו של המועדון הוא ה- Besoclub ניתן לאמר שחגיגות בר ובת המצווה רק תפסו תאוצה והתפתחו יותר ויותר בשנים האחרונות והדבר ייזקף לזכותו של המועדון הנ"ל שעומד בקצב הקידמה.

חגיגות בת המצווה הולכות והופכות לגדולות יותר, מושקעות יותר ותובעניות יותר.
כמעט אין נערה מתבגרת היום אשר מוכנה לוותר על הזכות לחגוג חגיגת בת מצווה מושקעת, להיות במרכז העניינים והבמה ולהרגיש, פעמים רבות בפעם הראשונה, כיצד אירוע גדול מופק במיוחד עבורן. אין נערה שלא אוהבת להיות במרכז תשומת הלב, וחגיגת בת המצווה מאפשרת זאת. בשנים האחרונות נפוצו מספר אירועים מיוחדים אותם ניתן להפיק לצורך חגיגת בת מצווה, אשר יכולים להפוך את האירוע לחגיגה בלתי נשכחת עבור הנערה. כאשר מתכננים את הפקת בת המצווה, כדאי לנסות ולחשוב על רעיונות מקוריים אשר יכולים להפוך את האירוע למיוחד יותר, מקורי יותר, שייזכר לפרק זמן רב לאחר סיומו. לצורך כך ניתנים כאן מספר רעיונות אותם ניתן לשלב במהלך חגיגת בת המצווה.

0 0

04 Dec 2013 11:17am GMT

אירוע אקסטרימי במועדון מסיבות

אירוע מסוג זה משלב חוויה אתגרית, העשויה לספק חוויה מיוחדת עבור המשתתפים בו.
אירוע מסוג זה יכול להפוך את החגיגה מכל סוג שהיא לאירוע מיוחד מאוד, ושונה באופיו ממסיבה רגילה.
חגיגות הנחגגות במועדונים מסוג זה יכולות להיות למשל טיול הישרדותי בשטח הכולל ניווט או טיפוס,
כאשר האירוע מתקיים בהדרכתו של צוות מיומן אשר עבר הכשרה קודמת לאירוע ונבחר בקפידה רבה.

ניתן לשלב באירוע מסוג זה למשל חוויות כגון ביצוע אומגה או סנפלינג, או במקרים מיוחדים גם לבצע אירוע באולם בו משולבים אלמנטים
של ספורט אקסטרים כגון אביזרים מיוחדים המופעלים באולם על ידי צוות מיוחד. ניתן לחפש עוד רעיונות בנושא ולמצוא בימינו המון חומר במרשתת האינטרנט ובייחוד ביוטיוב ישנם אירועים מעניינים ומאתגרים שנחגגו.

רעיונות נוספים לאירוע מסוג זה הוא למשל טיול ג'יפים משותף לכל המשתתפים באירוע.
נקודה חשובה שיש להוסיף היא שחשוב לדעת להתאים את האירוע לסוג המשתתפים,
אירוע מסוג זה מותאם לאנשים שיש להם חיבה משותפת לתחומים אלה.

דבר לא פחות חשוב הוא לשבת ולחשוב על תקציב מתאים לאירוע מכיוון שאין סוף לדרכים בהן ניתן לחגוג אותו.
רק לאחר מציאת התקציב המתאים, יכולים להתחיל ולחפש את סוג האירוע המתאים ואת האנשים הנכונים שיוכלו "לפקד"
על האירוע אותו תבחר.

המשך קריאה בנושא המסיבות והאירועים.

0 0

03 Dec 2013 11:15am GMT

Dear Community,


I am happy to announce this term's valid candidates as following


NAME == TMO Nickname == maemo.org Profile

Joseph Charpak == jcharpak == http://maemo.org/profile/view/jcharpak

Niel Nielsen == NielDK == http://maemo.org/profile/view/nieldk

Jussi Ohenoja == Juiceme == http://maemo.org/profile/view/juiceme

Joerg Reisenweber == joerg_rw == http://maemo.org/profile/view/joerg_rw

Ruediger Schiller == chemist == http://maemo.org/profile/view/chemist


Please see the wiki [1] for further information.

Stay tuned for your voting-token-mail within the next couple of days!


On behalf of the Maemo Community Council

Best regards

Ruediger Schiller
Community Council Chair

[1]http://wiki.maemo.org/Community_Council/Council_election_Q4_2013/Candidate_declarations

0 0

02 Dec 2013 9:04pm GMT

1 0

14 Nov 2013 3:47am GMT

Overview

CuteSpotify makes it possible to listen to your Spotify songs on Ubuntu Touch. It's based on MeeSpot (a MeeGo Spotify client), which I've updated to make use of Qt5 and Ubuntu's QML components. It's still a little rough around the edges but most of the core functionality is in place now.

One particular problem to look out for is that because of the way Ubuntu Touch currently handles applications CuteSpotify has to be kept in the foreground and the phone has to be kept switched on for music to play (otherwise the application gets suspended). Approaches for handling applications that need to keep running are currently being debated, so hopefully that won't be the case in future version of Ubuntu Touch.

As a temporary workaround, if your phone is in developer mode (achieved by connecting it up to the Ubuntu SDK) you can run "sudo service powerd stop" (default password is phablet) to stop the phone from going to sleep while you're listening to music, then "sudo service powerd start" to resume normal power management when you're done. (See popey's comment for an alternative method).

Video

Video of CuteSpotify running on Ubuntu Touch

Installation

To install CuteSpotify on Ubuntu Touch simply search for "CuteSpotify" on your phone and it should appear.

Source

The source code for CuteSpotify can be found here: https://github.com/Elleo/cutespotify

2 0

12 Nov 2013 12:18am GMT

In my ongoing uphill battle to maintain at least one meaningful post per year in this solitary monologue, here is the new entry I announced earlier today.

I must warn Planet Maemo purists (if there are still any) that it is not, stricto sensu, Maemo-related.

It is, however, a follow-up on previous posts dating back to 2009, so it is arguably not completely off-topic either :-)

You can read it on my new host & blog:

w4.monbo.net/blog/index.php?article33/a-foolish-consistency-is-the-hobgoblin-of-little-minds

0 0

11 Nov 2013 8:29pm GMT

Belatedly I have realized that going along with big old WordPress for this intermittent blog of mine was probably a mistake.

I use about 1% of its wealth of functionality, and not often enough to become proficient at it. It's also slow as molasses on this cheap host I've been using.

Moving to a better host (for many other reasons) also made me aware of the hassle involved in carrying over database contents for such apps.

So instead I painstakingly extracted my posts from WordPress and ported them to a much simpler, lighter and database-less blog app called PluXml.

There will be a post with actual content appearing shortly on this new media, which makes it two posts this year, a huge improvement on the previous ones :-)

The new IBTC is at http://w4.monbo.net/blog/ and the old one will probably disappear shortly.

1 0

11 Nov 2013 4:43pm GMT

About four years ago I created the first code for AGTL. It was built on previous experience I made with a very simple geocaching application for Android. Ever since, I kept AGTL running, first on the Openmoko Freerunner, then on the Nokia N900 (still a great phone!) and finally on the Nokia N9. And ever since, I had less time than I wanted to fix bugs, create new features and to stay in contact with you, the community.

A few days ago, I switched from the Nokia N9 to the Dark Side, a.k.a., Android (Nexus 5). With this switch I lost the ability to test new version of AGTL on the N9 and to use the software for myself (still the best method for finding bugs). Therefore, I decided to lay the responsibility for AGTL into the hands of somebody else. I decided to name Aapo Rantalainen as the new maintainer for AGTL. He caught my attention with many helpful bug reports and patches for AGTL, so I decided to pass the torch to him. Apparently, this has already paid off: Aapo made a lot of commits during the last days, fixing bugs and applying patches that I didn't have time for.

I hope to be able to help here and there with AGTL, and to stay up-to-date on its further development. New versions will be announced on this website.

Thanks to Aapo for taking the responsibility and to all the other people that provided me with bug reports, feature suggestions and (sometimes also monetary) input during the last years! It was definitely a great time and its not over yet!0 0

07 Nov 2013 8:00pm GMT

Overview

Eyrie is a music identification program that I originally created for the Nokia N9 but which I've now also ported to Ubuntu Touch. It works in a similar way to commercial applications like Shazam and SoundHound, listening to music through the phone's microphone and then generating an acoustic fingerprint using the open source EchoPrint algorithm. Currently the EchoPrint database isn't anywhere near as large as the various commercial offerings, so it won't recognise everything, but it has reasonable coverage.

Video

Video of Eyrie running on Ubuntu Touch

Installation

To install Eyrie on Ubuntu Touch simply search for "Eyrie" on your phone and it should appear.

2 0

07 Nov 2013 12:15am GMT

I've just release a new version of Tirelire 1.1.0. This minor release add a settings page, so you ll be able to set the currency symbol for the money you use.

1 0

05 Nov 2013 12:00am GMT

With all the talk about debian choosing a default init system (link, link), I've decided to share with the world a little project I've been working on to help me understand /sbin/init aka. PID 1.

In this blog post I will go step by step showing what an init system must do to be functional. I will ignore all the legacy SysVinit stuff, and technical nuances, and just concentrate on what's really important.

Introduction

First of all, what is 'init'? In it's essence it's a process that must be running at all times, if this process ends, the kernel enters into a panic mode, after which you cannot do anything else, except rebooting.

This process doesn't need to do anything special, you can use /bin/sh as your init, or even /bin/yes (although the latter wouldn't be very useful).

So let's write our very first init.

#!/usr/bin/ruby
Process.spawn('agetty', 'tty1')
sleep

Believe it or not, this is actually a rather useful init. How useful it is depends on how your kernel was compiled, your partitioning scheme, and if your root file-system is mounted rw or not. But either way, it covers the basics: rule #1; always keep running no matter what.

This is almost true, except that we need to be listening for SIGCHLD, otherwise some processes wouldn't be cleaned up properly, so:

Signal.trap(:SIGCHLD) do
  loop do
    begin
      status = Process.wait(-1, Process::WNOHANG)
      break if status == nil
    rescue Errno::ECHILD
      break
    end
  end
end

Reboot

Now that we have the running indefinitely under control, it's time to stop running (only when requested), but in order to do that we need some kind of IPC with the running process. There's many ways to achieve this, but I chose UNIX sockets to do that.

So instead of sleeping forever, we listen for commands issued to /run/initctl:

begin
  server = UNIXServer.open('/run/initctl')
rescue Errno::EADDRINUSE
  File.delete('/run/initctl')
  retry
end

loop do
  ctl = server.accept
  cmd = ctl.readline.chomp.to_sym
  # do stuff
end

And when the user is calling us with arguments, we pass those commands through /run/initctl.

def do_cmd(*cmd)
  ctl = UNIXSocket.open('/run/initctl')
  ctl.puts(cmd.join(' '))
  puts(ctl.readline.chomp)
  exit
end

case ARGV[0]
when 'poweroff', 'restart', 'halt'
  do_cmd(ARGV[0].to_sym)
end

So can issue the command init poweroff to turn off the machine, but in order to do that we need to tell the kernel:

def sys_reboot(cmd)
  map = { poweroff: 0x4321fedc, restart: 0x01234567, halt: 0xcdef0123 }
  syscall(169, 0xfee1dead, 537993216, map[cmd])
end

These numbers are not important, what is important is that the kernel understands them, and with this we actually turn off the machine (or halt, or reboot).

Thread carefully

Obviously it would be tedious to type a bunch of commands each time the machine starts, so we need to actually do stuff after booting, however, if we do something wrong, we might render the system unusable. A simple way to solve this is to use scripts, fork a shell, and let it run those, so if there's something wrong with the scripts, the shell dies, but not PID 1, so the system remains usable, which again, is rule #1.

Fortunately Ruby has exceptions, so we can run code with a safety net that catches all exceptions, and there's no need to fork, which would waste precious booting time.

def action(name)
  print(name)
  begin
    yield
  rescue => e
    print(' (error: %s)' % e)
  end
  puts
end

With this helper, we can safely run chunks of code, and if they fail, the error is reported to the user.

Initialization

This is the bulk of the code; the instructions you don't want to type every time. This is mostly tedious stuff, you can skim or skip this section safely.

def mount(type, device, dir, opts)
  Dir.mkdir(dir) unless File.directory?(dir)
  system('mount', '-t', type, device, dir, '-o', opts)
end

action 'Mounting virtual file-systems' do
  mount('proc', 'proc', '/proc', 'nosuid,noexec,nodev')
  mount('sysfs', 'sys', '/sys', 'nosuid,noexec,nodev')
  mount('tmpfs', 'run', '/run', 'mode=0755,nosuid,nodev')
  mount('devtmpfs', 'dev', '/dev', 'mode=0755,nosuid')
  mount('devpts', 'devpts', '/dev/pts', 'mode=0620,gid=5,nosuid,noexec')
  mount('tmpfs', 'shm', '/dev/shm', 'mode=1777,nosuid,nodev')
end

And set the hostname.

action 'Setting hostname' do
  hostname = File.read('/etc/hostname').chomp
  File.write('/proc/sys/kernel/hostname', hostname)
end

Notice that many things can go wrong, for example the file '/etc/hostname' might not exist, however, that would cause an exception, and our init would continue just fine.

Another thing we would want to do is kill all the processes, otherwise we might not be able to unmount the file-systems. We could do killall5, but we wouldn't have much control over the processes, and that would require a fork. Instead we can rely on the kernel to do the right thing, and all we have to do is wait for the results.

def killall

  def allgone?()
    Dir.glob('/proc/*').each do |e|
      pid = File.basename(e).to_i
      begin
        next if pid < 2
        # Is it a kernel process?
        next if File.read('/proc/%i/cmdline' % pid).empty?
      rescue Errno::ENOENT
      end
      return false
    end
    return true
  end

  def wait_until(timeout = 2, interval = 0.25)
    start = Time.now
    begin
      break true if yield
      sleep(interval)
    end while (Time.now - start) < timeout
  end

  ok = false

  action 'Sending SIGTERM to processes' do
    Process.kill(:SIGTERM, -1)
    ok = wait_until(10) { allgone? }
    raise 'Failed' unless ok
  end

  return if ok

  action 'Sending SIGKILL to processes' do
    Process.kill(:SIGKILL, -1)
    ok = wait_until(15) { allgone? }
    raise 'Failed' unless ok
  end

end

Time to mount real file-systems:

NETFS = %w[nfs nfs4 smbfs cifs codafs ncpfs shfs fuse fuseblk glusterfs davfs fuse.glusterfs]
VIRTFS = %w[proc sysfs tmpfs devtmpfs devpts]

action 'Mounting local filesystems' do
  except = NETFS.map { |e| 'no' + e }.join(',')
  system('mount', '-a', '-t', except, '-O', 'no_netdev')
end

# On shutdown

action 'Unmounting real filesystems' do
  except = (NETFS + VIRTFS).map { |e| 'no' + e }.join(',')
  system('umount', '-a', '-t', except, '-O', 'no_netdev')
end

If you are using a modern distribution, chances are your /run and /tmp directories are cleared up on every boot, so many files and directories need to be re-created. We could do this by hand, but we could also use the systemd-tmpfiles utility which uses the configuration already provided by your distribution in tmpfiles.d directories.

action 'Manage temporary files' do
  system('systemd-tmpfiles', '--create', '--remove', '--clean')
end

begin
  File.delete('/run/nologin')
rescue Errno::ENOENT
end

Unless you are using a custom kernel with modules built-in, chances are you are going to need udev, so fire it up:

action 'Starting udev daemon' do
  system('/usr/lib/systemd/systemd-udevd', '--daemon')
end

action 'Triggering udev uevents' do
  system('udevadm', 'trigger', '--action=add', '--type=subsystems')
  system('udevadm', 'trigger', '--action=add', '--type=devices')
end

action 'Waiting for udev uevents to be processed' do
  system('udevadm', 'settle')
end

# On shutdown

action 'Shutting down udev' do
  system('udevadm', 'control', '--exit')
end

Finally

After all this initialization stuff, your system is most likely very usable already, and in fact I was able to start a display manager (SLiM) at this point, which was my main goal while writing this. But we are just getting started.

In control

Another thing init should do is keep track of launched daemons. Each time we do that we store the PID, and when the child exists, we remove it from the list.

def start(id, cmd)
  $daemons[id] = Process.spawn(*cmd)
end

start('agetty1', %w[agetty tty1])

# On SIGCHLD
key = $daemons.key(status)
$daemons.delete(key) if key

Once we have this it's trivial to report the status of them (e.g. init status agetty1).

ctl.puts($daemons[args.first] ? 'ok' : 'dead')

At this point we actually have a feature that SysVinit doesn't have. Not bad for 200 lines of code!

cgroups

cgroups is a feature that is often misunderstood, probably because there are no good tools to make use of them, but they are not that hard. Lennart Pottering went to a lot of trouble trying to explain exactly what systemd does with them and it does not, but I don't think he did a very good job of clarifying anything. Basically systemd is not doing anything with them Normally systemd is not doing anything with them (by default), simply labeling processes so you can see how they are grouped by using visualization tools like systemd-cgls, but that's it.

The single most important way you can take advantage of cgroups is for scheduling purposes, so for example your web browser is a control group, and your heavy compilation is in another, then Linux scheduler would isolate the two processes from stealing resources from each other without the need of adjusting the nice level. Basically with cgroups there's no need for nice (although you can use alongside).

But you don't have to move a finger to get this benefit, the kernel already does that if you have CONFIG_SCHED_AUTOGROUP, which you should. Then, cgroups would be created for each session in the system, if you don't know what sessions are, you can run 'ps f -eo pid,sid,cmd' to find out to which session id each process belongs to.

To prove this I wrote a little script that finds out the auto-grouping as reported by the Linux kernel, and you can find groups like:

------------------------------------------------------------------------------
503     slim -nodaemon
895     /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
901     dbus-launch --sh-syntax --exit-with-session
938     xfce4-session
948     xfwm4
952     xfce4-panel
954     Thunar --daemon
956     xfdesktop
958     conky -q
964     nm-applet
------------------------------------------------------------------------------

This is exactly what you would expect, the session leader (SLiM) starts a bunch of processes, and all of them belong to the same session, and if I compile a Linux kernel, I get:

------------------------------------------------------------------------------
14584   zsh
17920   make
20610   make -f scripts/Makefile.build obj=arch/x86
20661   make -f scripts/Makefile.build obj=kernel
20715   make -f scripts/Makefile.build obj=mm
20734   make -f scripts/Makefile.build obj=arch/x86/kernel
20736   make -f scripts/Makefile.build obj=fs
20750   make -f scripts/Makefile.build obj=arch/x86/kvm
20758   make -f scripts/Makefile.build obj=arch/x86/mm
21245   make -f scripts/Makefile.build obj=ipc
21274   make -f scripts/Makefile.build obj=security
21281   make -f scripts/Makefile.build obj=security/keys
21376   /bin/sh -c set -e;         echo '  CC      mm/mmu_context.o'; ...
21378   gcc -Wp,-MD,mm/.mmu_context.o.d ...
21387   /bin/sh -c set -e;         echo '  CC      ipc/msg.o'; ...
21390   gcc -Wp,-MD,ipc/.msg.o.d ...
21395   /bin/sh -c set -e;         echo '  CC      kernel/extable.o'; ...
21399   /bin/sh -c set -e;         echo '  CC [M]  arch/x86/kvm/pmu.o'; ...
21400   gcc -Wp,-MD,kernel/.extable.o.d ...
21403   gcc -Wp,-MD,arch/x86/kvm/.pmu.o.d .
21405   /bin/sh -c set -e;         echo '  CC      arch/x86/kernel/probe_roms.o'; ...
21407   gcc -Wp,-MD,arch/x86/kernel/.probe_roms.o.d ...
21413   /bin/sh -c set -e;         echo '  CC      fs/inode.o'; ...
21415   /bin/sh -c set -e;         echo '  CC      arch/x86/mm/srat.o'; ...
21418   /bin/sh -c set -e;         echo '  CC      security/keys/keyctl.o'; ...
------------------------------------------------------------------------------

This group will contain a lot of processes that take a lot of resources, but the scheduler knows they belong to the same group. If somebody logs in to my machine and starts running folding@home we would have two cgroups trying to use 100% of the CPU, so the scheduler would assign 50% to one, and 50% to the other, even though the first one has many more processes. Without the grouping, the scheduler would be unfair against folding@home, giving it as much time as it gives each one of the compilation processes.

All this without you moving a finger. Well, almost.

def start(id, cmd)
  pid = fork do
    Process.setsid()
    exec(*cmd)
  end
  $daemons[id] = pid
end

Socket activation

systemd has made a lot of fuss about socket activation, and how it's the next best thing after sliced bread. I agree it's a great idea, but the idea didn't come from systemd, AFAIK it came from OSX. But, do we need systemd to get the same in Linux?

def start_with_socket(id, stream, cmd)

  server = TCPServer.new(stream)

  Thread.new do
    loop do
      socket = server.accept
      system(*cmd, :in => socket, : out => socket)
    end
  end

end

start_with_socket('sshd', 22, %w[/usr/bin/sshd -i])

Believe it or not, this simple code achieves socket activation. We create a socket, and a new thread that waits for connections, if nobody connects, nothing happens, we have an idle thread, each time somebody connects, we launch ssh -i, which as far as I can tell is the same thing xinetd does, and systemd.

But hey, this is the simple socket activation, it's not the really fancy one.

Thread.new do
  if managed
    IO.select([server])
    pid = fork do
      env = {}
      env['LISTEN_PID'] = $$.to_s
      env['LISTEN_FDS'] = 1.to_s
      Process.setsid()
      exec(env, *cmd, 3 => server)
    end
    $daemons[id] = pid
  else
    loop do
      socket = server.accept
      system(*cmd, :in => socket, : out => socket)
    end
  end
end

There, this does exactly the same thing as systemd (at least for one socket, multiple ones are easy too), so yeah, we have socket activation.

But wait, there's more

Hopefully this covers the basics of what an init system should do, and how it's not rocket science, nor voodoo. It is actually something very straightforward; start the system, keep it running, simple. Of course there's many other things an operating system should do, but those things don't belong to the init system, don't let anyone tell you otherwise.

I have more changes on top of this that bring my little toy init system almost up-to-par to Arch Linux's initscripts, which is what they used before moving to systemd, so chances are if you use my init, you would have little to no problems in your own system.

Unlike systemd and others, this code is actually very readable, so you can add and remove code as you like very easily, and of course, the less code you have, the faster you boot.

Personally when I hear somebody saying "Oh! but OpenRC doesn't have socket activation, we need systemd!", I just roll my eyes.

If you want to give it a try, get the code from GitHub:

https://github.com/felipec/finit

Cheers.

0 0

04 Nov 2013 4:23pm GMT

1 0

03 Nov 2013 9:24pm GMT

0 0

03 Nov 2013 5:55pm GMT

0 0

02 Nov 2013 3:41pm GMT

due to the lack of nominees we decided to extend the nomination period by one month.

From the merger with HiFo-Council we furthermore need to extend the election process by another week, adding a one-week contemplation period.

We are extending the acceptance of nominations till the end of the day 2013/11/30 (GMT).

Contemplation will start 2013/12/01 ending with the end of the day 2013/12/07 (GMT).

The Election then starts 2013/12/08. You will be notified with an election-token within the week before.

For detailed information on upcoming elections, general information about the process and if you are an eligible person to vote or as candidate - see:
Election Process http://wiki.maemo.org/Community_Council/Election_process

On behalf of the Maemo Community Council

Best regards
Ruediger Schiller
Community Council Chair

1 0

01 Nov 2013 7:57pm GMT

I ve just release a new software for Harmattan: Tirelire. A fast, easy to use, and simple expenses tracker.

Currently available only for Meego / Harmattan, port for SailfishOS and Nemo Mobile planned.

ScreenShots

More informations

2 0

26 Oct 2013 12:00am GMT