From kaplanlior at gmail.com  Fri May  1 08:50:10 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Fri, 1 May 2015 08:50:10 +0300
Subject: Mageia Linux mirror on http://mirror.isoc.org.il/content.html
In-Reply-To: <CAEsznC55_XhUjYf8PR+LNSmGOKyViAhCciP3f2p0kRhHjkqQ9Q@mail.gmail.com>
References: <CANy4znWBbTibbrXjHp3kPAZGSgKcBcM7_ZOsBgW4-bdn_W5PZQ@mail.gmail.com>
 <CAEsznC55_XhUjYf8PR+LNSmGOKyViAhCciP3f2p0kRhHjkqQ9Q@mail.gmail.com>
Message-ID: <CAEsznC7JDq1uoznXibatvTzM4QG=MhHdK4timMyyW-BLrHSyfQ@mail.gmail.com>

So it seems the initial sync takes much longer.

I expect another 24 hours.

Kaplan

On Wed, Apr 29, 2015 at 2:32 PM, Lior Kaplan <kaplanlior at gmail.com> wrote:

> http://mirror.isoc.org.il/pub/mageia/
>
> Please wait 24 hours for the mirror to sync.
>
> Per https://wiki.mageia.org/en/Mirrors_policy#Available_media I'm not
> syncing debug/* files.
>
> Kaplan
>
> On Tue, Apr 7, 2015 at 2:49 PM, Shlomi Fish <shlomif at gmail.com> wrote:
>
>> Hi,
>>
>> please set up a mirrors.isoc.org.il mirror of Mageia Linux (
>> http://www.mageia.org/en/ ; https://en.wikipedia.org/wiki/Mageia ),
>> which is a community fork of Mandriva and has largely succeeded it
>> (Mandriva did not have a release since 2011 , while Mageia released version
>> 4.1 in June 2014, and Mageia 5 should be released soon). isoc.org.il (
>> http://mirror.isoc.org.il/content.html ) already carries a mirror  of
>> Mandriva.
>>
>> If you're using Mageia Linux in Israel, please speak up by replying to
>> this message it will be known there's interest.
>>
>> Regards,
>>
>> -- Shlomi Fish
>>
>> --
>> ------------------------------------------
>> Shlomi Fish http://www.shlomifish.org/
>>
>> Chuck Norris helps the gods that help themselves.
>>
>> Please reply to list if it's a mailing list post - http://shlom.in/reply
>> .
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150501/a5533987/attachment.html>

From dov.grobgeld at gmail.com  Sat May  2 23:02:15 2015
From: dov.grobgeld at gmail.com (Dov Grobgeld)
Date: Sat, 2 May 2015 23:02:15 +0300
Subject: New router/modem
Message-ID: <CA++fsGGeCt5nRSfCS0J2eyWmJCccKKt_yYPitrUynku-hwuKqg@mail.gmail.com>

I need some advice regarding a new router modem. My old Linksys WRT54G
finally died on me, so I need to get a new router and I thought to replace
it with a combined router/modem. I looked on the cheapo Edimax ar-7186WnA
and on paper it seems to support almost everything I need. Things lacking
seem to be selectable DDNS server, different input and output ports for
portforwarding, but I realize that my always turned on raspberry pi 2 can
fill in for what is missing. Of course I am also giving up the ability to
put replacement firmware on the router, but in any case I was never doing
anything "interesting" with it, and again if I need some fancy stuff, I
guess that the raspberry can do it. I am currently using the "old" ADSL
connection, as I have not yet updated to NGN, but  if I understand things
correctly the 7186 supports Annex M needed for NGN, so I can always update.

Did I miss something? Does someone have any experience with this
modem/router or can you recommend something else?

Thanks in advance!
Dov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150502/ba3a4217/attachment.html>

From esr+linux-il at g.jct.ac.il  Sat May  2 23:55:40 2015
From: esr+linux-il at g.jct.ac.il (E.S. Rosenberg)
Date: Sat, 2 May 2015 23:55:40 +0300
Subject: New router/modem
In-Reply-To: <CA++fsGGeCt5nRSfCS0J2eyWmJCccKKt_yYPitrUynku-hwuKqg@mail.gmail.com>
References: <CA++fsGGeCt5nRSfCS0J2eyWmJCccKKt_yYPitrUynku-hwuKqg@mail.gmail.com>
Message-ID: <CAHTx_BN6L_xr-xyrBTVtBH_CaqquF1deoy1GWd+KTEBiwqwKKg@mail.gmail.com>

There was a recent discussion on the list on the subject where the
general consensus was to use a good router of your choosing and a
simple Bezeq modem, like that you can quicly and easily get new
technology supported (whether new DSL/cable by switching the modem or
new WiFi/LAN technologies by switching the router) and if you choose
your router right you also get to use openwrt or something similar....

The above is similar to the unix philosophy that one program should
have one task, one device one task....

The listed support of the device is indeed ADSL 2/2+ which Bezeq tends
to call NGN, though they also call their 100M NGN which is definitely
not provided with ADSL2....

Good luck,
Eliyahu - ?????

2015-05-02 23:02 GMT+03:00 Dov Grobgeld <dov.grobgeld at gmail.com>:
> I need some advice regarding a new router modem. My old Linksys WRT54G
> finally died on me, so I need to get a new router and I thought to replace
> it with a combined router/modem. I looked on the cheapo Edimax ar-7186WnA
> and on paper it seems to support almost everything I need. Things lacking
> seem to be selectable DDNS server, different input and output ports for
> portforwarding, but I realize that my always turned on raspberry pi 2 can
> fill in for what is missing. Of course I am also giving up the ability to
> put replacement firmware on the router, but in any case I was never doing
> anything "interesting" with it, and again if I need some fancy stuff, I
> guess that the raspberry can do it. I am currently using the "old" ADSL
> connection, as I have not yet updated to NGN, but  if I understand things
> correctly the 7186 supports Annex M needed for NGN, so I can always update.
>
> Did I miss something? Does someone have any experience with this
> modem/router or can you recommend something else?
>
> Thanks in advance!
> Dov
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>


From geoffreymendelson at gmail.com  Sun May  3 07:48:14 2015
From: geoffreymendelson at gmail.com (geoffrey mendelson)
Date: Sun, 03 May 2015 07:48:14 +0300
Subject: New router/modem
In-Reply-To: <CAHTx_BN6L_xr-xyrBTVtBH_CaqquF1deoy1GWd+KTEBiwqwKKg@mail.gmail.com>
References: <CA++fsGGeCt5nRSfCS0J2eyWmJCccKKt_yYPitrUynku-hwuKqg@mail.gmail.com>
 <CAHTx_BN6L_xr-xyrBTVtBH_CaqquF1deoy1GWd+KTEBiwqwKKg@mail.gmail.com>
Message-ID: <5545A88E.4040308@gmail.com>

On 5/2/2015 11:55 PM, E.S. Rosenberg wrote:
>
> The listed support of the device is indeed ADSL 2/2+ which Bezeq tends
> to call NGN, though they also call their 100M NGN which is definitely
> not provided with ADSL2....
>
ALL NGN is connected via vDSL hardware, with anything less than 15 
megabits and by request 15 megabits, in aDSL2 emulation mode. The 
emulation mode works poorly, if at all, and many people complain their 
router slows down or loses the connection in 24 to 48 hours and needs to 
be rebooted.

While they are required to provide the old support, they never tell 
people that is the problem and suggest that they upgrade their 
connection and router. If they don't it NEVER will work properly, and if 
they do, it works fine.

Geoff.

-- 
Geoffrey S. Mendelson 4X1GM/N3OWJ
Jerusalem Israel.



From mulix at mulix.org  Sun May  3 10:13:41 2015
From: mulix at mulix.org (Muli Ben-Yehuda)
Date: Sun, 3 May 2015 10:13:41 +0300
Subject: looking for a consultant for storage performance analysis work
Message-ID: <20150503071341.GB8162@needle>

A former client of mine is looking for a consultant experienced in
Linux for storage performance analysis work. The work should be on
site in Haifa and will probably last several months. Anyone?

Cheers,
Muli


From shlomo.solomon at gmail.com  Sun May  3 10:28:58 2015
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Sun, 3 May 2015 10:28:58 +0300
Subject: OT - non-HP ink
Message-ID: <20150503102858.3cde3921@shlomo1.solomon>

Sorry for the OT post, but the list is the only dependable forum I
could think of for this question.

I just bought an inkjet printer - HP 8610 - after years of using a
laser. I'm debating with myself about using original (i.e expensive)
or non-original ink.

I know that HP cannot void a warranty for using non-HP ink, but I'm
sure that any problems with print quality will always be "blamed" on
the ink.

I'd be glad to hear first-hand experience (good or bad) rgarding
non-HP ink - especially if someone is using this model or a similar
one.

thanks - again sorry for the OT  

-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.12.15 - LINUX Mageia 4



From geoffreymendelson at gmail.com  Sun May  3 12:10:00 2015
From: geoffreymendelson at gmail.com (geoffrey mendelson)
Date: Sun, 03 May 2015 12:10:00 +0300
Subject: OT - non-HP ink
In-Reply-To: <20150503102858.3cde3921@shlomo1.solomon>
References: <20150503102858.3cde3921@shlomo1.solomon>
Message-ID: <5545E5E8.3010902@gmail.com>

On 5/3/2015 10:28 AM, Shlomo Solomon wrote:
> Sorry for the OT post, but the list is the only dependable forum I
> could think of for this question.
>
> I just bought an inkjet printer - HP 8610 - after years of using a
> laser. I'm debating with myself about using original (i.e expensive)
> or non-original ink.

I bought a similar printer about a year and a half ago. I bought several 
sets of third party ink from a company I found on zap.

The ink worked great, but since I did not pay by paypal, and I did not 
get an email confirmation of the order, I have no idea of from whom I 
bought it.

The boxes and cartridges themselves are just plain generic refills.

I have since looked on eBay and found that due to the depressed Euro, I 
could get 4 sets of 4 cartridges (extra large black, magenta, cyan and 
yellow) for 200 NIS including registered mail from Germany.

In short I would do it again if the cartridges are just plain ink, but 
not if each cartridge includes a print head.


Geoff.

-- 
Geoffrey S. Mendelson 4X1GM/N3OWJ
Jerusalem Israel.



From dilogsys at inter.net.il  Sun May  3 13:20:22 2015
From: dilogsys at inter.net.il (dilogsys at inter.net.il)
Date: Sun, 03 May 2015 13:20:22 +0300
Subject: OT - non-HP ink
In-Reply-To: <20150503102858.3cde3921@shlomo1.solomon>
References: <20150503102858.3cde3921@shlomo1.solomon>
Message-ID: <54b0da5e21698.55462096@inter.net.il>

----- Original Message -----From: Shlomo Solomon <shlomo.solomon at gmail.com>Date: Sunday, May 3, 2015 10:29Subject: OT - non-HP inkTo: linux-il <linux-il at cs.huji.ac.il>> Sorry for the OT post, but the list is the only dependable forum I> could think of for this question.> > I just bought an inkjet printer - HP 8610 - after years of using a> laser. I'm debating with myself about using original (i.e expensive)> or non-original ink.> > I know that HP cannot void a warranty for using non-HP ink, but I'm> sure that any problems with print quality will always be > "blamed" on> the ink.> > I'd be glad to hear first-hand experience (good or bad) rgarding> non-HP ink - especially if someone is using this model or a similar> one.> > thanks - again sorry for the OT? > > -- > Shlomo Solomon> http://the-solomons.net> Sent by Claws Mail 3.11.1 - KDE 4.12.15 - LINUX Mageia 4> > > _______________________________________________> Linux-il mailing list> Linux-il at cs.huji.ac.il> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-ilI tried non HP ink on a 5610 and ran in to all sorts of quality related problems including smudging an lousy color performance..I also just switched to an 8610 - but I chose to "bite the bullet" and stay with genuine HP cartridges.It's a rip-off ...??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150503/b6a44348/attachment.html>

From dov.grobgeld at gmail.com  Sun May  3 14:15:44 2015
From: dov.grobgeld at gmail.com (Dov Grobgeld)
Date: Sun, 3 May 2015 14:15:44 +0300
Subject: OT - non-HP ink
In-Reply-To: <54b0da5e21698.55462096@inter.net.il>
References: <20150503102858.3cde3921@shlomo1.solomon>
 <54b0da5e21698.55462096@inter.net.il>
Message-ID: <CA++fsGGxvG_Jfnc1L9f9jWdk+GSRW9J7wyd_uGReNLmhK6A6Zw@mail.gmail.com>

The 8610 seems to be a popular printer on this list. I also got one.  I
also plan to stay with the original (expensive!) ink. Note that there is a
bug in printing 10x15 photos in Linux:

https://bugs.launchpad.net/hplip/+bug/1393043

Regards,
Dov




On Sun, May 3, 2015 at 1:20 PM, <dilogsys at inter.net.il> wrote:

> ----- Original Message -----
> From: Shlomo Solomon <shlomo.solomon at gmail.com>
> Date: Sunday, May 3, 2015 10:29
> Subject: OT - non-HP ink
> To: linux-il <linux-il at cs.huji.ac.il>
>
> > Sorry for the OT post, but the list is the only dependable forum I
> > could think of for this question.
> >
> > I just bought an inkjet printer - HP 8610 - after years of using a
> > laser. I'm debating with myself about using original (i.e expensive)
> > or non-original ink.
> >
> > I know that HP cannot void a warranty for using non-HP ink, but I'm
> > sure that any problems with print quality will always be
> > "blamed" on
> > the ink.
> >
> > I'd be glad to hear first-hand experience (good or bad) rgarding
> > non-HP ink - especially if someone is using this model or a similar
> > one.
> >
> > thanks - again sorry for the OT
> >
> > --
> > Shlomo Solomon
> > http://the-solomons.net
> > Sent by Claws Mail 3.11.1 - KDE 4.12.15 - LINUX Mageia 4
> >
> >
> > _______________________________________________
> > Linux-il mailing list
> > Linux-il at cs.huji.ac.il
> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
> I tried non HP ink on a 5610 and ran in to all sorts of quality related
> problems including smudging an lousy color performance..
>
> I also just switched to an 8610 - but I chose to "bite the bullet" and
> stay with genuine HP cartridges.
>
> It's a rip-off ...
>
>
>
> ??
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150503/a0f8450e/attachment.html>

From mordbe0 at gmail.com  Sun May  3 15:44:14 2015
From: mordbe0 at gmail.com (Mord Behar)
Date: Sun, 3 May 2015 15:44:14 +0300
Subject: OT - non-HP ink
In-Reply-To: <CA++fsGGxvG_Jfnc1L9f9jWdk+GSRW9J7wyd_uGReNLmhK6A6Zw@mail.gmail.com>
References: <20150503102858.3cde3921@shlomo1.solomon>
 <54b0da5e21698.55462096@inter.net.il>
 <CA++fsGGxvG_Jfnc1L9f9jWdk+GSRW9J7wyd_uGReNLmhK6A6Zw@mail.gmail.com>
Message-ID: <CAJzkJxF=gwcvf8uLvSxs8vA1CavmU-EUkE8PPX4R1HPhvQx2gg@mail.gmail.com>

My parents have a 5600 series printer and tried to use third party
cartridges. I'm not sure on the details, but my father has sworn off them
and now buys original HP ink.
I have a F2480 and also only buy original HP ink.
Anecdotally, I have heard that while third party cartridges are cheaper,
they print less pages per cartridge. I'm sorry to say that I don't have a
reliable source for this or any way to run the numbers, but presumably, in
the long run, non-HP ink doesn't pay.

On Sun, May 3, 2015 at 2:15 PM, Dov Grobgeld <dov.grobgeld at gmail.com> wrote:

> The 8610 seems to be a popular printer on this list. I also got one.  I
> also plan to stay with the original (expensive!) ink. Note that there is a
> bug in printing 10x15 photos in Linux:
>
> https://bugs.launchpad.net/hplip/+bug/1393043
>
> Regards,
> Dov
>
>
>
>
> On Sun, May 3, 2015 at 1:20 PM, <dilogsys at inter.net.il> wrote:
>
>> ----- Original Message -----
>> From: Shlomo Solomon <shlomo.solomon at gmail.com>
>> Date: Sunday, May 3, 2015 10:29
>> Subject: OT - non-HP ink
>> To: linux-il <linux-il at cs.huji.ac.il>
>>
>> > Sorry for the OT post, but the list is the only dependable forum I
>> > could think of for this question.
>> >
>> > I just bought an inkjet printer - HP 8610 - after years of using a
>> > laser. I'm debating with myself about using original (i.e expensive)
>> > or non-original ink.
>> >
>> > I know that HP cannot void a warranty for using non-HP ink, but I'm
>> > sure that any problems with print quality will always be
>> > "blamed" on
>> > the ink.
>> >
>> > I'd be glad to hear first-hand experience (good or bad) rgarding
>> > non-HP ink - especially if someone is using this model or a similar
>> > one.
>> >
>> > thanks - again sorry for the OT
>> >
>> > --
>> > Shlomo Solomon
>> > http://the-solomons.net
>> > Sent by Claws Mail 3.11.1 - KDE 4.12.15 - LINUX Mageia 4
>> >
>> >
>> > _______________________________________________
>> > Linux-il mailing list
>> > Linux-il at cs.huji.ac.il
>> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>> I tried non HP ink on a 5610 and ran in to all sorts of quality related
>> problems including smudging an lousy color performance..
>>
>> I also just switched to an 8610 - but I chose to "bite the bullet" and
>> stay with genuine HP cartridges.
>>
>> It's a rip-off ...
>>
>>
>>
>> ??
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150503/87957cfa/attachment-0001.html>

From slitt at troubleshooters.com  Mon May  4 17:50:50 2015
From: slitt at troubleshooters.com (Steve Litt)
Date: Mon, 4 May 2015 10:50:50 -0400
Subject: Linux boot documentation
Message-ID: <20150504105050.6b2d098c@mydesq2.domain.cxm>

Hi all,

I just documented the boot process, from Grub through init.

See http://troubleshooters.com/linux/diy/howboot.htm

Hope you like it.

SteveT


Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz


From geoffreymendelson at gmail.com  Thu May  7 09:16:20 2015
From: geoffreymendelson at gmail.com (geoffrey mendelson)
Date: Thu, 07 May 2015 09:16:20 +0300
Subject: Easy to use hex editor?
Message-ID: <554B0334.7010408@gmail.com>

Hi,

I have a DOS program I need to modify. I need to be able to load an DOS 
EXE file, and hopefully using a gui, search for ascii text and 8 byte 
floating point numbers in INTEL format and modify them. Then when I 
write the file it still needs to be be executable.

If it has a patch mode, where I can compare the patched version to the 
original and get a diff type output, I would really be happy.

I had a great one on my MAC, but I no longer have the MAC and would 
prefer to do it on a Linux system.

TIA for any suggestions.

Geoff.

-- 
Geoffrey S. Mendelson 4X1GM/N3OWJ
Jerusalem Israel.



From romovs at gmail.com  Thu May  7 09:39:51 2015
From: romovs at gmail.com (Roman Ovseitsev)
Date: Thu, 7 May 2015 09:39:51 +0300
Subject: Easy to use hex editor?
In-Reply-To: <554B0334.7010408@gmail.com>
References: <554B0334.7010408@gmail.com>
Message-ID: <CABjyLDy2LNPYhvjbcfV0k2HFAqjponYxOMmuM_EJ6nsJSQaDeg@mail.gmail.com>

wxHexEditor is rather feature rich and can diff files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150507/f0496cd0/attachment.html>

From shlomif at gmail.com  Thu May  7 11:34:14 2015
From: shlomif at gmail.com (Shlomi Fish)
Date: Thu, 7 May 2015 11:34:14 +0300
Subject: Easy to use hex editor?
In-Reply-To: <554B0334.7010408@gmail.com>
References: <554B0334.7010408@gmail.com>
Message-ID: <CANy4znVJcasVio6AummMYdcDbfRaLPotmbAF=OqMzAWL8aS24w@mail.gmail.com>

Hi Geoff,

On Thu, May 7, 2015 at 9:16 AM, geoffrey mendelson <
geoffreymendelson at gmail.com> wrote:

> Hi,
>
> I have a DOS program I need to modify. I need to be able to load an DOS
> EXE file, and hopefully using a gui, search for ascii text and 8 byte
> floating point numbers in INTEL format and modify them. Then when I write
> the file it still needs to be be executable.
>
>
If it has a patch mode, where I can compare the patched version to the
> original and get a diff type output, I would really be happy.
>
> I had a great one on my MAC, but I no longer have the MAC and would prefer
> to do it on a Linux system.
>
> TIA for any suggestions.
>

Hex editors that I like for Linux (in addition to what Roman said) are:

1. KDE's Okteta - https://utils.kde.org/projects/okteta/ - nice and seems
feature-rich - be aware of its "replace" vs. "insert/delete" modes.

2. https://wiki.gnome.org/Apps/Ghex - GNOME's GHex - easy to use but may
not be too feature-rich.

3. Vim/GVim have a utility for binary editing of files called "xxd" - I
don't have any real experience with it.

Regards,

-- Shlomi Fish

P.S: Perhaps I should add a list of hex editors somewhere under
http://www.shlomifish.org/open-source/resources/ (and I also want to add a
list of GUI builders like glade).


>
> Geoff.
>
> --
> Geoffrey S. Mendelson 4X1GM/N3OWJ
> Jerusalem Israel.
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>



-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Chuck Norris helps the gods that help themselves.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150507/ceeb2dfd/attachment.html>

From shlomif at gmail.com  Thu May  7 12:47:34 2015
From: shlomif at gmail.com (Shlomi Fish)
Date: Thu, 7 May 2015 12:47:34 +0300
Subject: Easy to use hex editor?
In-Reply-To: <CANy4znVJcasVio6AummMYdcDbfRaLPotmbAF=OqMzAWL8aS24w@mail.gmail.com>
References: <554B0334.7010408@gmail.com>
 <CANy4znVJcasVio6AummMYdcDbfRaLPotmbAF=OqMzAWL8aS24w@mail.gmail.com>
Message-ID: <CANy4znXyHv4G8ASKpzp3+svdQhAmLhSJ4J6gJ85xTvDLMK_-Nw@mail.gmail.com>

Hi all,

On Thu, May 7, 2015 at 11:34 AM, Shlomi Fish <shlomif at gmail.com> wrote:

> Hi Geoff,
>
> On Thu, May 7, 2015 at 9:16 AM, geoffrey mendelson <
> geoffreymendelson at gmail.com> wrote:
>
>> Hi,
>>
>> I have a DOS program I need to modify. I need to be able to load an DOS
>> EXE file, and hopefully using a gui, search for ascii text and 8 byte
>> floating point numbers in INTEL format and modify them. Then when I write
>> the file it still needs to be be executable.
>>
>>
> If it has a patch mode, where I can compare the patched version to the
>> original and get a diff type output, I would really be happy.
>>
>> I had a great one on my MAC, but I no longer have the MAC and would
>> prefer to do it on a Linux system.
>>
>> TIA for any suggestions.
>>
>
> Hex editors that I like for Linux (in addition to what Roman said) are:
>
> 1. KDE's Okteta - https://utils.kde.org/projects/okteta/ - nice and seems
> feature-rich - be aware of its "replace" vs. "insert/delete" modes.
>
> 2. https://wiki.gnome.org/Apps/Ghex - GNOME's GHex - easy to use but may
> not be too feature-rich.
>
> 3. Vim/GVim have a utility for binary editing of files called "xxd" - I
> don't have any real experience with it.
>
>
In addition to all that, I found this link in a DuckDuckGo search:

http://stackoverflow.com/questions/5498197/need-a-good-hex-editor-for-linux

There are quite a few recommendations there.

Regards,

? Shlomi Fish

-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Chuck Norris helps the gods that help themselves.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150507/2196928c/attachment.html>

From ehud at unix.mvs.co.il  Thu May  7 14:27:08 2015
From: ehud at unix.mvs.co.il (Ehud Karni)
Date: Thu, 7 May 2015 14:27:08 +0300
Subject: Easy to use hex editor?
In-Reply-To: <554B0334.7010408@gmail.com> (message from geoffrey mendelson on
 Thu, 07 May 2015 09:16:20 +0300)
References: <554B0334.7010408@gmail.com>
Message-ID: <201505071127.t47BR8FU021180@unix.mvs.co.il>

On Thu, 07 May 2015 09:16:20 +0300, geoffrey mendelson wrote:
>
> I have a DOS program I need to modify. I need to be able to load an DOS
> EXE file, and hopefully using a gui, search for ascii text and 8 byte
> floating point numbers in INTEL format and modify them. Then when I
> write the file it still needs to be be executable.
>
> If it has a patch mode, where I can compare the patched version to the
> original and get a diff type output, I would really be happy.

You can use `hexl-mode' in Emacs.
To hex-edit a file use the `hexl-find-file' Emacs command.

To compare the 2 files use `cmp' or `diff' on the output of `od -t x1 <file>`.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7976-561  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry


From gil at cs.technion.ac.il  Fri May  8 01:26:54 2015
From: gil at cs.technion.ac.il (Gili Granot)
Date: Fri, 08 May 2015 01:26:54 +0300
Subject: [JOB] Broadcom (ex Dune Networks) is hiring
Message-ID: <554BE6AE.6070404@cs.technion.ac.il>

Hi.

We are looking for graduates of top universities with high averages, and various levels of experience for these positions:
C software developers, to write the software controlling our devices.
Software development environment automation.
Electrical engineers in various fields: VLSI front end, DFT, physical design, architecture.

The software group writes the software (in C) that controls our products.
The software/driver runs on Linux.

We are located at Yakum, between Herzliya and Netanya.
We now can offer work also at our new Nazareth site.

Are you talented and want to work in a leading international communications company?
Do you want to work on cutting edge products and technologies used throughout the world?
Are you not afraid to strive for excellence and innovate?

Please send your CV to: gili at broadcom.com .

TIA
Gili


From shlomif at gmail.com  Sat May  9 12:01:13 2015
From: shlomif at gmail.com (Shlomi Fish)
Date: Sat, 9 May 2015 12:01:13 +0300
Subject: Mageia Linux mirror on http://mirror.isoc.org.il/content.html
In-Reply-To: <CAEsznC7JDq1uoznXibatvTzM4QG=MhHdK4timMyyW-BLrHSyfQ@mail.gmail.com>
References: <CANy4znWBbTibbrXjHp3kPAZGSgKcBcM7_ZOsBgW4-bdn_W5PZQ@mail.gmail.com>
 <CAEsznC55_XhUjYf8PR+LNSmGOKyViAhCciP3f2p0kRhHjkqQ9Q@mail.gmail.com>
 <CAEsznC7JDq1uoznXibatvTzM4QG=MhHdK4timMyyW-BLrHSyfQ@mail.gmail.com>
Message-ID: <CANy4znXpHU2dLLMr74SwtSCrVhVXkb=cEuoa9+OjD0cLHGh7nw@mail.gmail.com>

Hi Lior,

On Fri, May 1, 2015 at 8:50 AM, Lior Kaplan <kaplanlior at gmail.com> wrote:

> So it seems the initial sync takes much longer.
>
> I expect another 24 hours.
>
>
Has the mirror been synced already? Can we start using it now?

Regards,

-- Shlomi Fish


> Kaplan
>
>
-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Chuck Norris helps the gods that help themselves.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150509/7eb5db7d/attachment-0001.html>

From kaplanlior at gmail.com  Sat May  9 12:05:49 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Sat, 9 May 2015 12:05:49 +0300
Subject: Mageia Linux mirror on http://mirror.isoc.org.il/content.html
In-Reply-To: <CANy4znXpHU2dLLMr74SwtSCrVhVXkb=cEuoa9+OjD0cLHGh7nw@mail.gmail.com>
References: <CANy4znWBbTibbrXjHp3kPAZGSgKcBcM7_ZOsBgW4-bdn_W5PZQ@mail.gmail.com>
 <CAEsznC55_XhUjYf8PR+LNSmGOKyViAhCciP3f2p0kRhHjkqQ9Q@mail.gmail.com>
 <CAEsznC7JDq1uoznXibatvTzM4QG=MhHdK4timMyyW-BLrHSyfQ@mail.gmail.com>
 <CANy4znXpHU2dLLMr74SwtSCrVhVXkb=cEuoa9+OjD0cLHGh7nw@mail.gmail.com>
Message-ID: <CAEsznC5MsSdRXiOiV7CmHY0KefVcXMENE=U17z_G63SidB-1ow@mail.gmail.com>

On Sat, May 9, 2015 at 12:01 PM, Shlomi Fish <shlomif at gmail.com> wrote:

> Hi Lior,
>
> On Fri, May 1, 2015 at 8:50 AM, Lior Kaplan <kaplanlior at gmail.com> wrote:
>
>> So it seems the initial sync takes much longer.
>>
>> I expect another 24 hours.
>>
>>
> Has the mirror been synced already? Can we start using it now?
>
> Yes, go ahead.

Last successful sync date is kept in this file:
http://mirror.isoc.org.il/pub/info/mageia.log

Kaplan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150509/fe10337f/attachment.html>

From w1 at zak.co.il  Sun May 10 15:58:00 2015
From: w1 at zak.co.il (Omer Zak)
Date: Sun, 10 May 2015 15:58:00 +0300
Subject: In http://httpredir.debian.org/debian, do we use jessie-backports
 or jessie/backports?
Message-ID: <1431262680.23428.128.camel@zak.co.il>

When using the Debian apt system for updating packages, and when using
http://httpredir.debian.org/debian, do we use jessie-backports or
jessie/backports
Similarly - jessie-updates or jessie/updates?

The reason for my question:
When updating in aptitude, I sometimes got errors for some of the above.
Yet a Google search in Debian documentation did not give me a clear-cut
answer.

--- Omer



-- 
Feedback from one of the visitors to my
http://www.zak.co.il/deaf-info/old/ Web site:
"I found nothing helpful at this site so go to hell. Fuckers"
My own blog is at http://www.zak.co.il/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html



From efraim at flashner.co.il  Sun May 10 16:07:53 2015
From: efraim at flashner.co.il (Efraim Flashner)
Date: Sun, 10 May 2015 16:07:53 +0300
Subject: In http://httpredir.debian.org/debian, do we use
 jessie-backports or jessie/backports?
In-Reply-To: <1431262680.23428.128.camel@zak.co.il>
References: <1431262680.23428.128.camel@zak.co.il>
Message-ID: <20150510160753.2f103180@debian-netbook>

On Sun, 10 May 2015 15:58:00 +0300
Omer Zak <w1 at zak.co.il> wrote:

Good question-

> When using the Debian apt system for updating packages, and when using
> http://httpredir.debian.org/debian, do we use jessie-backports or
> jessie/backports
> Similarly - jessie-updates or jessie/updates?

I opened ftp.debian.org/debian and in ftp://ftp.debian.org/debian/dists/ it
shows jessie-backports and jessie-updates so that's what I'm going with.

> The reason for my question:
> When updating in aptitude, I sometimes got errors for some of the above.
> Yet a Google search in Debian documentation did not give me a clear-cut
> answer.
> 
> --- Omer

-- 
Efraim Flashner   <efraim at flashner.co.il>   ????? ?????
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150510/346cc22a/attachment.sig>

From amichai at iglu.org.il  Sun May 10 19:58:51 2015
From: amichai at iglu.org.il (Amichai Rotman)
Date: Sun, 10 May 2015 19:58:51 +0300
Subject: Accessing / Controling ProvisionISR DVR from Linux
Message-ID: <CAD_ZK64J1qUAZLEC+fud2PUthnGKOgiPbXUxRaK4y9etaMOEEw@mail.gmail.com>

Hi all,

A friend's coffee shop with a ProvisionISR DVR system. His main machine is
a laptop running Ubuntu 14.04.

He wants to access the DVR management through the browser, but when trying
it claims it needs to install an ActiveX (yuk!) to run, and it has no
support for Firefox / Google Chrome etc. (even under Windows)...

Any of you has any experience / ideas ?

Thanks!

Amichai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150510/58bb9c9c/attachment.html>

From esr+linux-il at g.jct.ac.il  Sun May 10 21:29:58 2015
From: esr+linux-il at g.jct.ac.il (E.S. Rosenberg)
Date: Sun, 10 May 2015 21:29:58 +0300
Subject: Accessing / Controling ProvisionISR DVR from Linux
In-Reply-To: <CAD_ZK64J1qUAZLEC+fud2PUthnGKOgiPbXUxRaK4y9etaMOEEw@mail.gmail.com>
References: <CAD_ZK64J1qUAZLEC+fud2PUthnGKOgiPbXUxRaK4y9etaMOEEw@mail.gmail.com>
Message-ID: <CAHTx_BMET+qPk9Ht2fy63t2VFWM9j976Vw=2tDiH8dBZ7_-SBg@mail.gmail.com>

Re:all
I have no experience with these things, but if you can't get around
the IE/ActiveX requirement (firmware upgrade maybe?) and decide to
capitulate you could try installing IE using winetricks...

HTH,
Eliyahu - ?????

2015-05-10 19:58 GMT+03:00 Amichai Rotman <amichai at iglu.org.il>:
> Hi all,
>
> A friend's coffee shop with a ProvisionISR DVR system. His main machine is a
> laptop running Ubuntu 14.04.
>
> He wants to access the DVR management through the browser, but when trying
> it claims it needs to install an ActiveX (yuk!) to run, and it has no
> support for Firefox / Google Chrome etc. (even under Windows)...
>
> Any of you has any experience / ideas ?
>
> Thanks!
>
> Amichai
>
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>


From rabin at rabin.io  Sun May 10 22:34:30 2015
From: rabin at rabin.io (Rabin Yasharzadehe)
Date: Sun, 10 May 2015 22:34:30 +0300
Subject: Accessing / Controling ProvisionISR DVR from Linux
In-Reply-To: <CAD_ZK64J1qUAZLEC+fud2PUthnGKOgiPbXUxRaK4y9etaMOEEw@mail.gmail.com>
References: <CAD_ZK64J1qUAZLEC+fud2PUthnGKOgiPbXUxRaK4y9etaMOEEw@mail.gmail.com>
Message-ID: <CABKuJEApZnuymEEiGp1VU5Qn6T3iTsqTNnFB_ZPw-HfKJ3hSEg@mail.gmail.com>

???????? ??? ?? ??????? ???? ???? ????? ????? ?? ??? ???? ???? ??? ?????
??? ?? ?????,
???? ???????? ?? ?????? ????? ???? ???? ?????? ???? ?????????? ?????? ????
(?? ?? ?????? ?? ?? ???? ?-andorid) ??? ?? ?? ?? ???? ????.

?????? ????? ????? ????? ??? ?? VM ?? XP ?? IE6\7\8 ?????? ?????? ????
????? ????? ?? ???? ????.

?.? ?? ???? ??????? ???? ????????? DESKTOP ???????? ????.
??? ????? ????? - ftp://ftp.loks.lv/DVR/RIFATRON/
?? ???? ??? ????? ??? ?? ?? ?? ???? ???? ?????? ???? ?-WEB.


--
Rabin

On Sun, May 10, 2015 at 7:58 PM, Amichai Rotman <amichai at iglu.org.il> wrote:

> Hi all,
>
> A friend's coffee shop with a ProvisionISR DVR system. His main machine is
> a laptop running Ubuntu 14.04.
>
> He wants to access the DVR management through the browser, but when trying
> it claims it needs to install an ActiveX (yuk!) to run, and it has no
> support for Firefox / Google Chrome etc. (even under Windows)...
>
> Any of you has any experience / ideas ?
>
> Thanks!
>
> Amichai
>
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150510/2340efb9/attachment.html>

From shlomo.solomon at gmail.com  Mon May 11 11:59:24 2015
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Mon, 11 May 2015 11:59:24 +0300
Subject: TV tuner or video capture card recommendation
Message-ID: <20150511115924.34d94d1a@shlomo1.solomon>

I have a VERY old no-name PCI TV tuner which has started to cause
problems (choppy video and no sound). Until recently it worked fine
and I could watch TV using TVtime or XawTV. I honestly don't know if
the problem is software (maybe caused by an upgrade?) or hardware (a bad
cable or connection or the card itself). But because it's so old, it's
probably not worth saving.

There are lots of articles on the net about hardware, drivers,
installation, what works or doesn't, etc. But I'm looking for firsthand
experience. For example, I've seen various articles about EasyCap or
EZCap working/not working. I do know that there are several similar
pieces of hardware using different chipsets, so it's hard to depend on
these articles. In fact, about a year ago I bought a card on eBay but
had no luck getting it to work.

My needs are really simple:
1 - USB connection
2 - can capture analog video and audio from a YES "MEMIR"
3 - works on Mageia and/or Raspberry PI Raspbian
4 - preferably work with TVtime, but any other workable software is OK


-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.12.15 - LINUX Mageia 4



From gilboad at gmail.com  Tue May 12 12:27:26 2015
From: gilboad at gmail.com (Gilboa Davara)
Date: Tue, 12 May 2015 12:27:26 +0300
Subject: TV tuner or video capture card recommendation
In-Reply-To: <20150511115924.34d94d1a@shlomo1.solomon>
References: <20150511115924.34d94d1a@shlomo1.solomon>
Message-ID: <CAGw18x+Y0t=9egUWQJdkbhHucOAQ5vUsCJ=ntoW13LJLi=dLow@mail.gmail.com>

On Mon, May 11, 2015 at 11:59 AM, Shlomo Solomon
<shlomo.solomon at gmail.com> wrote:
> I have a VERY old no-name PCI TV tuner which has started to cause
> problems (choppy video and no sound). Until recently it worked fine
> and I could watch TV using TVtime or XawTV. I honestly don't know if
> the problem is software (maybe caused by an upgrade?) or hardware (a bad
> cable or connection or the card itself). But because it's so old, it's
> probably not worth saving.
>
> There are lots of articles on the net about hardware, drivers,
> installation, what works or doesn't, etc. But I'm looking for firsthand
> experience. For example, I've seen various articles about EasyCap or
> EZCap working/not working. I do know that there are several similar
> pieces of hardware using different chipsets, so it's hard to depend on
> these articles. In fact, about a year ago I bought a card on eBay but
> had no luck getting it to work.
>
> My needs are really simple:
> 1 - USB connection
> 2 - can capture analog video and audio from a YES "MEMIR"
> 3 - works on Mageia and/or Raspberry PI Raspbian
> 4 - preferably work with TVtime, but any other workable software is OK
>

I'm using the Hauppauge HD PVR (I think its the 1212) to manually
record (via bash scripts) programs at 720P from a HOT set-top box
component connector.
(In essences, I simply cat /dev/videoN into file using cron).
It uses the in-tree hdpvr drive, so it should work out-of-the-box on
most/all modern distributions.
CPU usage is rather low, but its currently connected to one of my Xeon
workstations, so your R-PI millage may vary.

Hope it helps.

- Gilboa


From shlomif at gmail.com  Fri May 15 10:29:37 2015
From: shlomif at gmail.com (Shlomi Fish)
Date: Fri, 15 May 2015 10:29:37 +0300
Subject: Donate to Creative Commons [was Fwd: Fw: This SpaceX image is free]
Message-ID: <CANy4znXoNPVgOq4pjMnowme+tJ2_zZTR69VDiYUhHCrkKtGpFQ@mail.gmail.com>

Hi all,

please consider donating to Creative Commons.

Regards,

? Shlomi Fish

---------- Forwarded message ----------
From: Shlomi Fish <shlomif at shlomifish.org>
Date: Fri, May 15, 2015 at 10:25 AM
Subject: Fw: This SpaceX image is free
To: shlomif at gmail.com




Begin forwarded message:

Date: Thu, 14 May 2015 09:57:46 -0700
From: "Ryan Merkley" <info at creativecommons.org>
To: Shlomi Fish <shlomif at shlomifish.org>
Subject: This SpaceX image is free


Creative Commons
Shlomi,

More than two-thirds of the Commons exists on content platforms
like Flickr, YouTube, Vimeo, Soundcloud, and Wikipedia. The main
way people share with Creative Commons is by using the platforms
they already know and love, so working with them is vital.

The SpaceX image linked below and over 300,000 other images in
the public domain wouldn't be freely available if it wasn't for
CC.

<
https://donate.creativecommons.org/sites/all/modules/civicrm/extern/url.php?u=3988&qid=1382504
>

To meet our strategic goal of growing the Commons, we must have
the resources to continue developing our relationships with
content platforms. Will you help fund this crucial work by
making a $25 or more contribution to our $50,000 fundraising
drive?

<
https://donate.creativecommons.org/sites/all/modules/civicrm/extern/url.php?u=3986&qid=1382504
>

Last year, CC had no resources dedicated to working with content
platforms. This year, we've begun to change that, and are
already seeing results. Just last week, the popular writing
platform Medium added the CC license suite, and in April Flickr
added CC0 and the Public Domain Mark -- their first major update
to CC licensing since they first adopted the licenses.

We saw the benefits almost instantly: in the first two weeks
after Flickr added CC0, over 130,000 new images were added,
including all of the spectacular images from SpaceX.

Across the Commons, we need to update our tools and
technology. We want to support unique licensing IDs to allow
content analytics; improve discovery and curation through better
search; and drive more collaboration and contribution to the
global photography archive through our mobile app beta, The
List.

Those are just a few of the exciting projects we're working on,
but our ability to continue depends on raising the funds
necessary to support our work.

Help us grow the Commons. Ensure Creative Commons integration on
platforms and the development of new tools to make CC licenses
easier and more useful to creators and re-mixers by making a
contribution today!

<
https://donate.creativecommons.org/sites/all/modules/civicrm/extern/url.php?u=3986&qid=1382504
>

Thank you for your continued support.

Ryan
To opt-out of any future mailings from Creative Commons, simply visit this
URL:
https://donate.creativecommons.org/civicrm/mailing/optout?reset=1&jid=1590&qid=1382504&h=7181fa97af36359f

Creative Commons
PO Box 1866
Mountain View, CA
94042
United States


https://donate.creativecommons.org/sites/all/modules/civicrm/extern/url.php?u=3987&qid=1382504
Contact CC at info at creativecommons.org.

--
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
My Photos - http://www.flickr.com/photos/shlomif/

Confucius says: ?XSLT made me realise humanity was hopeless.?.
    ? http://www.shlomifish.org/humour/bits/facts/XSLT/

Please reply to list if it's a mailing list post - http://shlom.in/reply .



-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Chuck Norris helps the gods that help themselves.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150515/a4163c07/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150515/a4163c07/Originalhtmlpart-0001.html>

From elazarl at gmail.com  Fri May 15 17:47:13 2015
From: elazarl at gmail.com (Elazar Leibovich)
Date: Fri, 15 May 2015 17:47:13 +0300
Subject: Memory pool interface design
Message-ID: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>

I'm writing a small C library, that I want to open source.

I want them to be usable for embedded environment, where memory allocation
must be controlled.

Hence, I abstracted away calls to malloc/realloc, and replaced them with

struct mem_pool {
    void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
};

User would implement

struct my_mem_pool {
    struct mem_pool pool;
    ...
};

struct my_mem_pool pool = { { my_alloc_func }, ...);

I've had to design question I'm interested with:

1) Should I support both malloc and realloc?

I think the performance benefits of supporting malloc instead of
realloc(NULL) are negligible, and not worth complicating the interface.

2) Should the memory pool be allowed to fail?

In typical Linux system, where memory overcommit is allowed, checking
malloc return value provides little benefit. But is it the same for
embedded system?

My feeling is, embedded system should predict the memory usage for each
input size, and avoid processing input which is too large.

For example, stack overflow error can never be handled, and one is expected
to calculate the longest stack length for any input and make sure he
wouldn't overflow.

So I think it's still reasonable never to report allocation failure, and to
expect the memory allocator to raise the relevant abort/panic/exception in
such a case.

But I'll be happy to hear other considerations I missed.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150515/4b9a8cdb/attachment.html>

From baruch at ev-en.org  Fri May 15 21:00:15 2015
From: baruch at ev-en.org (Baruch Even)
Date: Fri, 15 May 2015 21:00:15 +0300
Subject: Memory pool interface design
In-Reply-To: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
Message-ID: <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>

I would question the need to abstract away the memory allocations of your
library compared to everything else. If someone cares enough about it he
can replace malloc and free completely to use a different allocation scheme.

In most cases I've cared about memory allocations I just wanted none of
them at all and only wanted intrusive data structures and just running the
system with a fixed memory allocation from the start to the end. It's not
always possible in a generic library though..

If you are writing a library you should never abort inside it, that would
be very annoying to the user. Give him a null and let him crash or handle
it as he sees fit.

Baruch

On Fri, May 15, 2015 at 5:47 PM, Elazar Leibovich <elazarl at gmail.com> wrote:

> I'm writing a small C library, that I want to open source.
>
> I want them to be usable for embedded environment, where memory allocation
> must be controlled.
>
> Hence, I abstracted away calls to malloc/realloc, and replaced them with
>
> struct mem_pool {
>     void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
> };
>
> User would implement
>
> struct my_mem_pool {
>     struct mem_pool pool;
>     ...
> };
>
> struct my_mem_pool pool = { { my_alloc_func }, ...);
>
> I've had to design question I'm interested with:
>
> 1) Should I support both malloc and realloc?
>
> I think the performance benefits of supporting malloc instead of
> realloc(NULL) are negligible, and not worth complicating the interface.
>
> 2) Should the memory pool be allowed to fail?
>
> In typical Linux system, where memory overcommit is allowed, checking
> malloc return value provides little benefit. But is it the same for
> embedded system?
>
> My feeling is, embedded system should predict the memory usage for each
> input size, and avoid processing input which is too large.
>
> For example, stack overflow error can never be handled, and one is
> expected to calculate the longest stack length for any input and make sure
> he wouldn't overflow.
>
> So I think it's still reasonable never to report allocation failure, and
> to expect the memory allocator to raise the relevant abort/panic/exception
> in such a case.
>
> But I'll be happy to hear other considerations I missed.
>
> Thanks,
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150515/fcd298c5/attachment.html>

From elazarl at gmail.com  Sat May 16 21:14:25 2015
From: elazarl at gmail.com (Elazar Leibovich)
Date: Sat, 16 May 2015 21:14:25 +0300
Subject: Memory pool interface design
In-Reply-To: <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
Message-ID: <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>

The question of whether to use a global malloc function, or to use a
function pointer is orthogonal to my question.

My question is, should I support the case of malloc failure. On one hand,
it complicates the API significantly, but on the other hand it might be
useful for some use cases.

It's pretty obvious to me that in a modern Linux userspace program,
supporting malloc failure does not worth the trouble. But are there other
use cases where it's vital?

Another clarification, my code would never have abort. What I was saying,
that the malloc could simply abort current task, if it does not have memory.

As a side note, In my experience, it is sometimes useful to use
preallocated "memory pools"[0]. Letting the user choose memory allocator is
also useful when using it in the kernel, since otherwise the library simply
won't compile. See for example protobuf-c which receives an allocator in
its functions,
https://github.com/protobuf-c/protobuf-c/blob/master/protobuf-c/protobuf-c.c#L2019


[0]
http://eli.thegreenplace.net/2008/10/17/memmgr-a-fixed-pool-memory-allocator

On Fri, May 15, 2015 at 9:00 PM, Baruch Even <baruch at ev-en.org> wrote:

> I would question the need to abstract away the memory allocations of your
> library compared to everything else. If someone cares enough about it he
> can replace malloc and free completely to use a different allocation scheme.
>
> In most cases I've cared about memory allocations I just wanted none of
> them at all and only wanted intrusive data structures and just running the
> system with a fixed memory allocation from the start to the end. It's not
> always possible in a generic library though..
>
> If you are writing a library you should never abort inside it, that would
> be very annoying to the user. Give him a null and let him crash or handle
> it as he sees fit.
>
> Baruch
>
> On Fri, May 15, 2015 at 5:47 PM, Elazar Leibovich <elazarl at gmail.com>
> wrote:
>
>> I'm writing a small C library, that I want to open source.
>>
>> I want them to be usable for embedded environment, where memory
>> allocation must be controlled.
>>
>> Hence, I abstracted away calls to malloc/realloc, and replaced them with
>>
>> struct mem_pool {
>>     void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
>> };
>>
>> User would implement
>>
>> struct my_mem_pool {
>>     struct mem_pool pool;
>>     ...
>> };
>>
>> struct my_mem_pool pool = { { my_alloc_func }, ...);
>>
>> I've had to design question I'm interested with:
>>
>> 1) Should I support both malloc and realloc?
>>
>> I think the performance benefits of supporting malloc instead of
>> realloc(NULL) are negligible, and not worth complicating the interface.
>>
>> 2) Should the memory pool be allowed to fail?
>>
>> In typical Linux system, where memory overcommit is allowed, checking
>> malloc return value provides little benefit. But is it the same for
>> embedded system?
>>
>> My feeling is, embedded system should predict the memory usage for each
>> input size, and avoid processing input which is too large.
>>
>> For example, stack overflow error can never be handled, and one is
>> expected to calculate the longest stack length for any input and make sure
>> he wouldn't overflow.
>>
>> So I think it's still reasonable never to report allocation failure, and
>> to expect the memory allocator to raise the relevant abort/panic/exception
>> in such a case.
>>
>> But I'll be happy to hear other considerations I missed.
>>
>> Thanks,
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150516/cbba3e53/attachment.html>

From ladypine at gmail.com  Sat May 16 22:10:29 2015
From: ladypine at gmail.com (Orna Agmon Ben-Yehuda)
Date: Sat, 16 May 2015 22:10:29 +0300
Subject: Memory pool interface design
In-Reply-To: <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
Message-ID: <CAA8-RXi7j8B0XF2sjs2--3LimD2qgtzaRJQanrNTXPtqN1Niug@mail.gmail.com>

Hi Elazar,

I find that malloc failure checking is vital (within the user program) even
on a regular system with gigabytes of memory. For example, when the program
gets into a recursive loop which allocates memory and then digs deeper. In
other cases, It is useful to check the return value of malloc when the
program input size is unlimited, and it is better to inform the user about
the too-large element of the input rather than to crash.

I do not understand, however, how memory overcommitment leads you to not
require malloc to fail. Maybe when you say overcommitment you do not mean
what I mean, but in our scenario[1] of memory overcommitment, where memory
balloon drivers are used, we configured the memory allocations to fail when
there was not enough physical memory, so that the guest application would
be able to tell when there is memory pressure. Otherwise, the burden of
handling memory pressure is laid purely on the operating system itself.

[1]  Ginseng: Market-Driven Memory Allocation
<http://www.cs.technion.ac.il/~ladypine/vee18-agmon-ben-yehuda.pdf>, Orna
Agmon Ben-Yehuda, Eyal Posener, Muli Ben-Yehuda, Assaf Schuster, Ahuva
Mu'alem. In proceedings of VEE 2014.


On Sat, May 16, 2015 at 9:14 PM, Elazar Leibovich <elazarl at gmail.com> wrote:

> The question of whether to use a global malloc function, or to use a
> function pointer is orthogonal to my question.
>
> My question is, should I support the case of malloc failure. On one hand,
> it complicates the API significantly, but on the other hand it might be
> useful for some use cases.
>
> It's pretty obvious to me that in a modern Linux userspace program,
> supporting malloc failure does not worth the trouble. But are there other
> use cases where it's vital?
>
> Another clarification, my code would never have abort. What I was saying,
> that the malloc could simply abort current task, if it does not have memory.
>
> As a side note, In my experience, it is sometimes useful to use
> preallocated "memory pools"[0]. Letting the user choose memory allocator is
> also useful when using it in the kernel, since otherwise the library simply
> won't compile. See for example protobuf-c which receives an allocator in
> its functions,
> https://github.com/protobuf-c/protobuf-c/blob/master/protobuf-c/protobuf-c.c#L2019
>
>
> [0]
> http://eli.thegreenplace.net/2008/10/17/memmgr-a-fixed-pool-memory-allocator
>
> On Fri, May 15, 2015 at 9:00 PM, Baruch Even <baruch at ev-en.org> wrote:
>
>> I would question the need to abstract away the memory allocations of your
>> library compared to everything else. If someone cares enough about it he
>> can replace malloc and free completely to use a different allocation scheme.
>>
>> In most cases I've cared about memory allocations I just wanted none of
>> them at all and only wanted intrusive data structures and just running the
>> system with a fixed memory allocation from the start to the end. It's not
>> always possible in a generic library though..
>>
>> If you are writing a library you should never abort inside it, that would
>> be very annoying to the user. Give him a null and let him crash or handle
>> it as he sees fit.
>>
>> Baruch
>>
>> On Fri, May 15, 2015 at 5:47 PM, Elazar Leibovich <elazarl at gmail.com>
>> wrote:
>>
>>> I'm writing a small C library, that I want to open source.
>>>
>>> I want them to be usable for embedded environment, where memory
>>> allocation must be controlled.
>>>
>>> Hence, I abstracted away calls to malloc/realloc, and replaced them with
>>>
>>> struct mem_pool {
>>>     void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
>>> };
>>>
>>> User would implement
>>>
>>> struct my_mem_pool {
>>>     struct mem_pool pool;
>>>     ...
>>> };
>>>
>>> struct my_mem_pool pool = { { my_alloc_func }, ...);
>>>
>>> I've had to design question I'm interested with:
>>>
>>> 1) Should I support both malloc and realloc?
>>>
>>> I think the performance benefits of supporting malloc instead of
>>> realloc(NULL) are negligible, and not worth complicating the interface.
>>>
>>> 2) Should the memory pool be allowed to fail?
>>>
>>> In typical Linux system, where memory overcommit is allowed, checking
>>> malloc return value provides little benefit. But is it the same for
>>> embedded system?
>>>
>>> My feeling is, embedded system should predict the memory usage for each
>>> input size, and avoid processing input which is too large.
>>>
>>> For example, stack overflow error can never be handled, and one is
>>> expected to calculate the longest stack length for any input and make sure
>>> he wouldn't overflow.
>>>
>>> So I think it's still reasonable never to report allocation failure, and
>>> to expect the memory allocator to raise the relevant abort/panic/exception
>>> in such a case.
>>>
>>> But I'll be happy to hear other considerations I missed.
>>>
>>> Thanks,
>>>
>>> _______________________________________________
>>> Linux-il mailing list
>>> Linux-il at cs.huji.ac.il
>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>
>>>
>>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 
Orna Agmon Ben-Yehuda.
http://ladypine.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150516/04ae3b16/attachment-0001.html>

From elazarl at gmail.com  Sat May 16 22:27:45 2015
From: elazarl at gmail.com (Elazar Leibovich)
Date: Sat, 16 May 2015 22:27:45 +0300
Subject: Memory pool interface design
In-Reply-To: <CAA8-RXi7j8B0XF2sjs2--3LimD2qgtzaRJQanrNTXPtqN1Niug@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <CAA8-RXi7j8B0XF2sjs2--3LimD2qgtzaRJQanrNTXPtqN1Niug@mail.gmail.com>
Message-ID: <CAHNTFmK1_EgXC1Pm62JEpNsHOxQtzk=ALJZmzcb-0DGBni9g6w@mail.gmail.com>

Thanks Orna,

My understanding is, that in stock Linux kernel, a process that allocates
too much memory is unlikely to receive NULL from malloc. The more likely
scenario is, the whole system would swap out pages, and the OOM killer
would, hopefully, kill the offending process. During that time it is
unlikely that malloc would return NULL.

Indeed, if you look at actual applications written for Linux, you'd see
that many use variants of xmalloc, which simply aborts if malloc returns
NULL. I think that the logic is similar to what I wrote before.

I thought to give a list of such real world programs, but someone wrote it
much better than I did:

http://eli.thegreenplace.net/2009/10/30/handling-out-of-memory-conditions-in-c

But feel free to correct me if I'm wrong.

PS,
I think we have miscommunication here, since from what I understand the
paper linked is about memory allocation for a VM, while I'm talking about
memory allocation for a process.

On Sat, May 16, 2015 at 10:10 PM, Orna Agmon Ben-Yehuda <ladypine at gmail.com>
wrote:

> Hi Elazar,
>
> I find that malloc failure checking is vital (within the user program)
> even on a regular system with gigabytes of memory. For example, when the
> program gets into a recursive loop which allocates memory and then digs
> deeper. In other cases, It is useful to check the return value of malloc
> when the program input size is unlimited, and it is better to inform the
> user about the too-large element of the input rather than to crash.
>
> I do not understand, however, how memory overcommitment leads you to not
> require malloc to fail. Maybe when you say overcommitment you do not mean
> what I mean, but in our scenario[1] of memory overcommitment, where memory
> balloon drivers are used, we configured the memory allocations to fail when
> there was not enough physical memory, so that the guest application would
> be able to tell when there is memory pressure. Otherwise, the burden of
> handling memory pressure is laid purely on the operating system itself.
>
> [1]  Ginseng: Market-Driven Memory Allocation
> <http://www.cs.technion.ac.il/~ladypine/vee18-agmon-ben-yehuda.pdf>, Orna
> Agmon Ben-Yehuda, Eyal Posener, Muli Ben-Yehuda, Assaf Schuster, Ahuva
> Mu'alem. In proceedings of VEE 2014.
>
>
> On Sat, May 16, 2015 at 9:14 PM, Elazar Leibovich <elazarl at gmail.com>
> wrote:
>
>> The question of whether to use a global malloc function, or to use a
>> function pointer is orthogonal to my question.
>>
>> My question is, should I support the case of malloc failure. On one hand,
>> it complicates the API significantly, but on the other hand it might be
>> useful for some use cases.
>>
>> It's pretty obvious to me that in a modern Linux userspace program,
>> supporting malloc failure does not worth the trouble. But are there other
>> use cases where it's vital?
>>
>> Another clarification, my code would never have abort. What I was saying,
>> that the malloc could simply abort current task, if it does not have memory.
>>
>> As a side note, In my experience, it is sometimes useful to use
>> preallocated "memory pools"[0]. Letting the user choose memory allocator is
>> also useful when using it in the kernel, since otherwise the library simply
>> won't compile. See for example protobuf-c which receives an allocator in
>> its functions,
>> https://github.com/protobuf-c/protobuf-c/blob/master/protobuf-c/protobuf-c.c#L2019
>>
>>
>> [0]
>> http://eli.thegreenplace.net/2008/10/17/memmgr-a-fixed-pool-memory-allocator
>>
>> On Fri, May 15, 2015 at 9:00 PM, Baruch Even <baruch at ev-en.org> wrote:
>>
>>> I would question the need to abstract away the memory allocations of
>>> your library compared to everything else. If someone cares enough about it
>>> he can replace malloc and free completely to use a different allocation
>>> scheme.
>>>
>>> In most cases I've cared about memory allocations I just wanted none of
>>> them at all and only wanted intrusive data structures and just running the
>>> system with a fixed memory allocation from the start to the end. It's not
>>> always possible in a generic library though..
>>>
>>> If you are writing a library you should never abort inside it, that
>>> would be very annoying to the user. Give him a null and let him crash or
>>> handle it as he sees fit.
>>>
>>> Baruch
>>>
>>> On Fri, May 15, 2015 at 5:47 PM, Elazar Leibovich <elazarl at gmail.com>
>>> wrote:
>>>
>>>> I'm writing a small C library, that I want to open source.
>>>>
>>>> I want them to be usable for embedded environment, where memory
>>>> allocation must be controlled.
>>>>
>>>> Hence, I abstracted away calls to malloc/realloc, and replaced them with
>>>>
>>>> struct mem_pool {
>>>>     void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
>>>> };
>>>>
>>>> User would implement
>>>>
>>>> struct my_mem_pool {
>>>>     struct mem_pool pool;
>>>>     ...
>>>> };
>>>>
>>>> struct my_mem_pool pool = { { my_alloc_func }, ...);
>>>>
>>>> I've had to design question I'm interested with:
>>>>
>>>> 1) Should I support both malloc and realloc?
>>>>
>>>> I think the performance benefits of supporting malloc instead of
>>>> realloc(NULL) are negligible, and not worth complicating the interface.
>>>>
>>>> 2) Should the memory pool be allowed to fail?
>>>>
>>>> In typical Linux system, where memory overcommit is allowed, checking
>>>> malloc return value provides little benefit. But is it the same for
>>>> embedded system?
>>>>
>>>> My feeling is, embedded system should predict the memory usage for each
>>>> input size, and avoid processing input which is too large.
>>>>
>>>> For example, stack overflow error can never be handled, and one is
>>>> expected to calculate the longest stack length for any input and make sure
>>>> he wouldn't overflow.
>>>>
>>>> So I think it's still reasonable never to report allocation failure,
>>>> and to expect the memory allocator to raise the relevant
>>>> abort/panic/exception in such a case.
>>>>
>>>> But I'll be happy to hear other considerations I missed.
>>>>
>>>> Thanks,
>>>>
>>>> _______________________________________________
>>>> Linux-il mailing list
>>>> Linux-il at cs.huji.ac.il
>>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>>
>
>
> --
> Orna Agmon Ben-Yehuda.
> http://ladypine.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150516/cc423634/attachment.html>

From pub at goldshmidt.org  Sat May 16 23:18:37 2015
From: pub at goldshmidt.org (Oleg Goldshmidt)
Date: Sat, 16 May 2015 23:18:37 +0300
Subject: Memory pool interface design
In-Reply-To: <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
Message-ID: <87oalk2s4i.fsf@goldshmidt.org>

Elazar Leibovich <elazarl at gmail.com> writes:

> My question is, should I support the case of malloc failure. On one
> hand, it complicates the API significantly, but on the other hand it
> might be useful for some use cases.

This sounds like, can you guys tell me what my requirements are? ;-)

If I understand correctly, you want to provide an alternative (to the
standard malloc() and friends) mechanism for memory allocation,
targeting primarily embedded systems. If I am not completely wrong,
consider the following:

1. Is "mechanism" the operative word? If so, then you should leave
   *policies* - including exception handling - to the client. If you
   intend to restrict your library to a single OOM excepton policy you
   should document the restricton. E.g., if your policy is going to be
   "segfault" or "commit a clean(ish) seppuku", you should tell
   potential users, using big bold red letters, "if this doesn't suit you
   don't use the library."  How much this will affect your library's
   usefulness/popularity I don't care to predict.

2. Naively, I cannot imagine *not* letting clients of a
   production-quality library decide what to do, if only to write
   something sensible to a log using the client's preferred format and
   destination. Some 20 year ago I saw popular (numerical) libraries
   whose authors (probably members of the academia) considered abort a
   legitimate way of handling failures. A scientist running a numerical
   application with the ultimate purpose of writing a paper certainly is
   justified in thinking that way. We, however, disqualified those
   libraries for any production use for that reason alone, regardless of
   their other qualities. IIRC we liked one of them enough to find *all*
   the places where it aborted and modify the code (FOSS rules, huh?).

3. There are enough examples of custom allocators. I am sure you can
   find an awful lot of code, say, overriding new/delete in C++. Even
   the standard libraries provide for overriding allocators. Find a few
   reputable example, see how exceptions are handled, follow the
   pattern? I suspect in most cases it is left to the library clients
   (arguably easier with longjumping exceptions than with C-style error
   propagation, but the point is, library code does not decide,
   usually).

4. What *are* your requirements? If a git client (an example you cited)
   tries to malloc, gets NULL, tries to recover, and then gives up and
   dies writing something to stderr, that's one thing. An embedded
   device just crashing without telling anyone what's wrong? Maybe a
   different kettle of fish altogether. Do you target devices with
   limited or somewhat limited - resources? May make a difference.

5. You mentioned swapping. That does not mean you are out of memory
   (malloc does not fail whan you swap pages). But I am sure you know
   that.

6. Kernel's OOM killer mechanism is also not directly related to
   malloc() failing. It means that *some* process, not necessarily (or
   even likely) the process that is requesting memory at the moment,
   will be killed, according to some policy. No one can decide in
   advance whether killing *something* is a good decision in an
   unspecified embedded system.

7. Why do you say handling failures will complicate the API a lot? It is
   not clear from what you wrote. After all, malloc() is not more
   complex because it can return NULL, is it? So can your alloc() member
   - what's the problem?

-- 
Oleg Goldshmidt | pub at goldshmidt.org


From elazarl at gmail.com  Sun May 17 00:04:49 2015
From: elazarl at gmail.com (Elazar Leibovich)
Date: Sun, 17 May 2015 00:04:49 +0300
Subject: Memory pool interface design
In-Reply-To: <87oalk2s4i.fsf@goldshmidt.org>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <87oalk2s4i.fsf@goldshmidt.org>
Message-ID: <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>

I think that I didn't explain myself correctly.

Let me try again.

I'm writing a C library, and I want it to be useful not only in Linux
userland, but also in other contexts, such as embedded devices, and inside
the Linux kernel.

This library sometimes allocates memory.

If I'll just allocate memory with malloc, my library wouldn't even compile
with embedded devices. Hence, I'll receive an allocator function from the
user, and use it to allocate memory.

A concrete example, a "regular" read_line function

char *read_line(struct reader *r) { char *rv = malloc(len); read_to(rv);
return rv; }

A more flexible read_line function:

char *read_line(struct reader *r, struct mem_pool *pool) { char *rv =
pool->alloc(pool, len); read_to(rv); return rv; }

Now I'm fine, because I can define pool->alloc to be kmalloc in the kernel
context, or use preallocated pools in embedded device.

What should I do if memory allocation fails? I can return an error for the
user, but it makes the API more complicated. Since many functions would
have to return error just in case of memory allocation failure.

Our read_line example would now look like

struct error read_line(struct reader *r, char **line);

And users would have to check error at each invocation.

I think I can avoid that. What do I intend to do?

My library would assume each memory allocation is successful, and the
client that provides the memory allocator would be responsible to failure
handling.

For example, in a "regular" linux userspace program, the mem_pool would be
something like

void *linux_userspace_mem_pool(struct mem_pool *pool, int size) {
   void *rv = malloc(size);
   if (rv == NULL) {
       syslog("ENOMEM");
       exit(0);
   }
}

An embedded client could throw an exception, or longjmp to the main loop,
or reset the system.

Now my question is, is that a reasonable behavior that would suite embedded
devices. I do not have enough experience to know that. Indeed, since I'm
writing a library that I hope would serve as broad audience as possible, it
is hard to know the requirements in advance.

Hence, I think 1-4 are already addressed, I always gives the user control
what would happen when he's out of memory.

Regarding 5-6. What I'm saying is, seeing malloc returning NULL in
production is very rare. I personally never seen that. I think that the OOM
killer would wreck havoc to the system before it would happen, hence,
crashing when malloc returns NULL is a reasonable behavior.

Regarding 7, this does not complicate the allocation API, it complicates my
API, since I'll have functions that cannot fail, generally speaking, but
allocates memory. Those would have to return error, and the user would have
to check the error.

Thanks,


On Sat, May 16, 2015 at 11:18 PM, Oleg Goldshmidt <pub at goldshmidt.org>
wrote:

> Elazar Leibovich <elazarl at gmail.com> writes:
>
> > My question is, should I support the case of malloc failure. On one
> > hand, it complicates the API significantly, but on the other hand it
> > might be useful for some use cases.
>
> This sounds like, can you guys tell me what my requirements are? ;-)
>
> If I understand correctly, you want to provide an alternative (to the
> standard malloc() and friends) mechanism for memory allocation,
> targeting primarily embedded systems. If I am not completely wrong,
> consider the following:
>
> 1. Is "mechanism" the operative word? If so, then you should leave
>    *policies* - including exception handling - to the client. If you
>    intend to restrict your library to a single OOM excepton policy you
>    should document the restricton. E.g., if your policy is going to be
>    "segfault" or "commit a clean(ish) seppuku", you should tell
>    potential users, using big bold red letters, "if this doesn't suit you
>    don't use the library."  How much this will affect your library's
>    usefulness/popularity I don't care to predict.
>
> 2. Naively, I cannot imagine *not* letting clients of a
>    production-quality library decide what to do, if only to write
>    something sensible to a log using the client's preferred format and
>    destination. Some 20 year ago I saw popular (numerical) libraries
>    whose authors (probably members of the academia) considered abort a
>    legitimate way of handling failures. A scientist running a numerical
>    application with the ultimate purpose of writing a paper certainly is
>    justified in thinking that way. We, however, disqualified those
>    libraries for any production use for that reason alone, regardless of
>    their other qualities. IIRC we liked one of them enough to find *all*
>    the places where it aborted and modify the code (FOSS rules, huh?).
>
> 3. There are enough examples of custom allocators. I am sure you can
>    find an awful lot of code, say, overriding new/delete in C++. Even
>    the standard libraries provide for overriding allocators. Find a few
>    reputable example, see how exceptions are handled, follow the
>    pattern? I suspect in most cases it is left to the library clients
>    (arguably easier with longjumping exceptions than with C-style error
>    propagation, but the point is, library code does not decide,
>    usually).
>
> 4. What *are* your requirements? If a git client (an example you cited)
>    tries to malloc, gets NULL, tries to recover, and then gives up and
>    dies writing something to stderr, that's one thing. An embedded
>    device just crashing without telling anyone what's wrong? Maybe a
>    different kettle of fish altogether. Do you target devices with
>    limited or somewhat limited - resources? May make a difference.
>
> 5. You mentioned swapping. That does not mean you are out of memory
>    (malloc does not fail whan you swap pages). But I am sure you know
>    that.
>
> 6. Kernel's OOM killer mechanism is also not directly related to
>    malloc() failing. It means that *some* process, not necessarily (or
>    even likely) the process that is requesting memory at the moment,
>    will be killed, according to some policy. No one can decide in
>    advance whether killing *something* is a good decision in an
>    unspecified embedded system.
>
> 7. Why do you say handling failures will complicate the API a lot? It is
>    not clear from what you wrote. After all, malloc() is not more
>    complex because it can return NULL, is it? So can your alloc() member
>    - what's the problem?
>
> --
> Oleg Goldshmidt | pub at goldshmidt.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150517/cf88ba36/attachment-0001.html>

From guy.choo.keren at gmail.com  Sun May 17 02:09:45 2015
From: guy.choo.keren at gmail.com (guy keren)
Date: Sun, 17 May 2015 02:09:45 +0300
Subject: Memory pool interface design
In-Reply-To: <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <87oalk2s4i.fsf@goldshmidt.org>
 <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
Message-ID: <5557CE39.4050303@gmail.com>


as a rule - if it's a general-purpose library,k and it can fail - it 
must return an error using the language's natural error mechanism.
in C - this comes as a return status.

i *have* seen malloc returning NULL in some situations.

the application that uses your library may decide to simply terminate 
the service provided by the specific thread, or it can decide to forgo 
freeing memory it is holding in different parts of the code, or.....

what you are trying to do is behave in a non-C-like manner. this is 
counter-productive.

on the other hand - this is your library - do whatever you want, and 
we'll see what the users decide to do with it.

--guy

On 05/17/2015 12:04 AM, Elazar Leibovich wrote:
> I think that I didn't explain myself correctly.
>
> Let me try again.
>
> I'm writing a C library, and I want it to be useful not only in Linux
> userland, but also in other contexts, such as embedded devices, and
> inside the Linux kernel.
>
> This library sometimes allocates memory.
>
> If I'll just allocate memory with malloc, my library wouldn't even
> compile with embedded devices. Hence, I'll receive an allocator function
> from the user, and use it to allocate memory.
>
> A concrete example, a "regular" read_line function
>
> char *read_line(struct reader *r) { char *rv = malloc(len); read_to(rv);
> return rv; }
>
> A more flexible read_line function:
>
> char *read_line(struct reader *r, struct mem_pool *pool) { char *rv =
> pool->alloc(pool, len); read_to(rv); return rv; }
>
> Now I'm fine, because I can define pool->alloc to be kmalloc in the
> kernel context, or use preallocated pools in embedded device.
>
> What should I do if memory allocation fails? I can return an error for
> the user, but it makes the API more complicated. Since many functions
> would have to return error just in case of memory allocation failure.
>
> Our read_line example would now look like
>
> struct error read_line(struct reader *r, char **line);
>
> And users would have to check error at each invocation.
>
> I think I can avoid that. What do I intend to do?
>
> My library would assume each memory allocation is successful, and the
> client that provides the memory allocator would be responsible to
> failure handling.
>
> For example, in a "regular" linux userspace program, the mem_pool would
> be something like
>
> void *linux_userspace_mem_pool(struct mem_pool *pool, int size) {
>     void *rv = malloc(size);
>     if (rv == NULL) {
>         syslog("ENOMEM");
>         exit(0);
>     }
> }
>
> An embedded client could throw an exception, or longjmp to the main
> loop, or reset the system.
>
> Now my question is, is that a reasonable behavior that would suite
> embedded devices. I do not have enough experience to know that. Indeed,
> since I'm writing a library that I hope would serve as broad audience as
> possible, it is hard to know the requirements in advance.
>
> Hence, I think 1-4 are already addressed, I always gives the user
> control what would happen when he's out of memory.
>
> Regarding 5-6. What I'm saying is, seeing malloc returning NULL in
> production is very rare. I personally never seen that. I think that the
> OOM killer would wreck havoc to the system before it would happen,
> hence, crashing when malloc returns NULL is a reasonable behavior.
>
> Regarding 7, this does not complicate the allocation API, it complicates
> my API, since I'll have functions that cannot fail, generally speaking,
> but allocates memory. Those would have to return error, and the user
> would have to check the error.
>
> Thanks,
>
>
> On Sat, May 16, 2015 at 11:18 PM, Oleg Goldshmidt <pub at goldshmidt.org
> <mailto:pub at goldshmidt.org>> wrote:
>
>     Elazar Leibovich <elazarl at gmail.com <mailto:elazarl at gmail.com>> writes:
>
>     > My question is, should I support the case of malloc failure. On one
>     > hand, it complicates the API significantly, but on the other hand it
>     > might be useful for some use cases.
>
>     This sounds like, can you guys tell me what my requirements are? ;-)
>
>     If I understand correctly, you want to provide an alternative (to the
>     standard malloc() and friends) mechanism for memory allocation,
>     targeting primarily embedded systems. If I am not completely wrong,
>     consider the following:
>
>     1. Is "mechanism" the operative word? If so, then you should leave
>         *policies* - including exception handling - to the client. If you
>         intend to restrict your library to a single OOM excepton policy you
>         should document the restricton. E.g., if your policy is going to be
>         "segfault" or "commit a clean(ish) seppuku", you should tell
>         potential users, using big bold red letters, "if this doesn't
>     suit you
>         don't use the library."  How much this will affect your library's
>         usefulness/popularity I don't care to predict.
>
>     2. Naively, I cannot imagine *not* letting clients of a
>         production-quality library decide what to do, if only to write
>         something sensible to a log using the client's preferred format and
>         destination. Some 20 year ago I saw popular (numerical) libraries
>         whose authors (probably members of the academia) considered abort a
>         legitimate way of handling failures. A scientist running a numerical
>         application with the ultimate purpose of writing a paper
>     certainly is
>         justified in thinking that way. We, however, disqualified those
>         libraries for any production use for that reason alone,
>     regardless of
>         their other qualities. IIRC we liked one of them enough to find
>     *all*
>         the places where it aborted and modify the code (FOSS rules, huh?).
>
>     3. There are enough examples of custom allocators. I am sure you can
>         find an awful lot of code, say, overriding new/delete in C++. Even
>         the standard libraries provide for overriding allocators. Find a few
>         reputable example, see how exceptions are handled, follow the
>         pattern? I suspect in most cases it is left to the library clients
>         (arguably easier with longjumping exceptions than with C-style error
>         propagation, but the point is, library code does not decide,
>         usually).
>
>     4. What *are* your requirements? If a git client (an example you cited)
>         tries to malloc, gets NULL, tries to recover, and then gives up and
>         dies writing something to stderr, that's one thing. An embedded
>         device just crashing without telling anyone what's wrong? Maybe a
>         different kettle of fish altogether. Do you target devices with
>         limited or somewhat limited - resources? May make a difference.
>
>     5. You mentioned swapping. That does not mean you are out of memory
>         (malloc does not fail whan you swap pages). But I am sure you know
>         that.
>
>     6. Kernel's OOM killer mechanism is also not directly related to
>         malloc() failing. It means that *some* process, not necessarily (or
>         even likely) the process that is requesting memory at the moment,
>         will be killed, according to some policy. No one can decide in
>         advance whether killing *something* is a good decision in an
>         unspecified embedded system.
>
>     7. Why do you say handling failures will complicate the API a lot? It is
>         not clear from what you wrote. After all, malloc() is not more
>         complex because it can return NULL, is it? So can your alloc()
>     member
>         - what's the problem?
>
>     --
>     Oleg Goldshmidt | pub at goldshmidt.org <mailto:pub at goldshmidt.org>
>
>
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>



From pub at goldshmidt.org  Sun May 17 21:51:35 2015
From: pub at goldshmidt.org (Oleg Goldshmidt)
Date: Sun, 17 May 2015 21:51:35 +0300
Subject: Memory pool interface design
In-Reply-To: <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <87oalk2s4i.fsf@goldshmidt.org>
 <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
Message-ID: <87k2w72g20.fsf@goldshmidt.org>

Elazar Leibovich <elazarl at gmail.com> writes:

> Regarding 5-6. What I'm saying is, seeing malloc returning NULL in
> production is very rare. 

Hope dies last.. ;-)

> I personally never seen that. 

So you've been lucky so far. At some point you will inevitably run into
client code that occasionally does something stupid like passing a
signed integer as size. Trust me, when that happens the size parameter
usually turns out to be -6. You will have no control over it.
  
> I think that the OOM killer would wreck havoc to the system before it
> would happen,

Why do you assume that? How *can* you assume that given that OOM
policies can be configured (at runtime)?

Apart from everything else, why do you assume that malloc only fails
when there is not enough memory? 

And if you allow - nay, require! - that the user specifies a custom
allocator, how do you know *that* won't fail for some weird (or
perfectly logical, as the case may be) reason?

> hence, crashing when malloc returns NULL is a reasonable behavior.

For a non-critical single process application under very special
circumstances - maybe. What if the crash happens while client code is
tweaking some shared memory, holding a lock or some other resource
(where a crash would leave some data your library does not control in an
inconsistent state that will cause problems for other processes or after
restart), or in general needs to do some cleanup / bookkeeping / logging
(to tell the user what happened) before dying - how can you possibly
call hard crash "reasonable behaviour"?

> Regarding 7, this does not complicate the allocation API, it
> complicates my API, since I'll have functions that cannot fail,
> generally speaking, but allocates memory.

This implies that you need to handle allocation (and all other) errors
inside such functions to provide the "no exceptions" guarantee. Your
options, in order of increased sophistication (you can actually do this
in stages and hope to get feedback rather than being ignored):

1. Decide how and do that - that's a policy. See if this is attractve to
   your users. Hope to get emails saying "I wish you didn't abort."

   [If you get such emails feel very proud - someone cares enough, you
   probably did a very good job on everything else.]

2. Provide several different policies and a configuration mechanism to
   choose - see if this is more successful than #1 above. Hope to get
   emails saying "I wish you would add this other policy."

3. Provide a callback hook so that a user can implement and register a
   handler - effectively, support custom policies.

   By the time you get to this stage you may realize that you may just
   as well return a status code and let the user handle the
   condition. I expect this to be easier for users than registering
   callbacks. It will also be more flexible since different policies may
   be applied in different places in a single client program.

> Those would have to return error, and the user would have to check the
> error.

As both Guy and I said before, this is the proper behaviour for a
general purpose library.

-- 
Oleg Goldshmidt | pub at goldshmidt.org


From ladypine at gmail.com  Sun May 17 22:08:58 2015
From: ladypine at gmail.com (Orna Agmon Ben-Yehuda)
Date: Sun, 17 May 2015 22:08:58 +0300
Subject: Memory pool interface design
In-Reply-To: <CAHNTFmK1_EgXC1Pm62JEpNsHOxQtzk=ALJZmzcb-0DGBni9g6w@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <CAA8-RXi7j8B0XF2sjs2--3LimD2qgtzaRJQanrNTXPtqN1Niug@mail.gmail.com>
 <CAHNTFmK1_EgXC1Pm62JEpNsHOxQtzk=ALJZmzcb-0DGBni9g6w@mail.gmail.com>
Message-ID: <CAA8-RXgyx4DveUSucSvCAHFRiFb5fmVPA-z4SBxke0sCnwczzg@mail.gmail.com>

On Sat, May 16, 2015 at 10:27 PM, Elazar Leibovich <elazarl at gmail.com>
wrote:

> Thanks Orna,
>
> My understanding is, that in stock Linux kernel, a process that allocates
> too much memory is unlikely to receive NULL from malloc. The more likely
> scenario is, the whole system would swap out pages, and the OOM killer
> would, hopefully, kill the offending process. During that time it is
> unlikely that malloc would return NULL.
>
>
Oleg already mentioned that OOM kills an arbitrary process, not necessarily
the one causing problems=failing a malloc. But even if it did kill the
process which failed the malloc, this is not necessarily the correct
behavior. I am considering a world in which applications are expected to be
aware of memory pressure. In this case, process where the malloc failed is
not necessarily the one that needs to crash or even free memory. There
might be other measures that need to be taken before it happens. For
example, an elastic application should release memory. An example for such
a scenario is when you work with postgresql, which relies on storing data
in cached pages. It can release memory easily, and make room for the failed
malloc to succeed. Another option is for the balloon device driver to
deflate, and by that make room for malloc.



> Indeed, if you look at actual applications written for Linux, you'd see
> that many use variants of xmalloc, which simply aborts if malloc returns
> NULL. I think that the logic is similar to what I wrote before.
>
> I thought to give a list of such real world programs, but someone wrote it
> much better than I did:
>
>
> http://eli.thegreenplace.net/2009/10/30/handling-out-of-memory-conditions-in-c
>
> But feel free to correct me if I'm wrong.
>
> PS,
> I think we have miscommunication here, since from what I understand the
> paper linked is about memory allocation for a VM, while I'm talking about
> memory allocation for a process.
>
>
No miscommunication. Indeed our paper deals with allocating memory to VMs,
but to make things work we needed to handle swapping and memory allocation,
even returning memory from libc to the operating system, all to make the
memory allocation of one process behave elastically. See section 7 for the
changes we made to the operating system configuration. Our processes
certainly need to get the return value from malloc and live, even if we get
NULL, which we might get many times as a healthy progress of things.


> On Sat, May 16, 2015 at 10:10 PM, Orna Agmon Ben-Yehuda <
> ladypine at gmail.com> wrote:
>
>> Hi Elazar,
>>
>> I find that malloc failure checking is vital (within the user program)
>> even on a regular system with gigabytes of memory. For example, when the
>> program gets into a recursive loop which allocates memory and then digs
>> deeper. In other cases, It is useful to check the return value of malloc
>> when the program input size is unlimited, and it is better to inform the
>> user about the too-large element of the input rather than to crash.
>>
>> I do not understand, however, how memory overcommitment leads you to not
>> require malloc to fail. Maybe when you say overcommitment you do not mean
>> what I mean, but in our scenario[1] of memory overcommitment, where memory
>> balloon drivers are used, we configured the memory allocations to fail when
>> there was not enough physical memory, so that the guest application would
>> be able to tell when there is memory pressure. Otherwise, the burden of
>> handling memory pressure is laid purely on the operating system itself.
>>
>> [1]  Ginseng: Market-Driven Memory Allocation
>> <http://www.cs.technion.ac.il/~ladypine/vee18-agmon-ben-yehuda.pdf>,
>> Orna Agmon Ben-Yehuda, Eyal Posener, Muli Ben-Yehuda, Assaf Schuster, Ahuva
>> Mu'alem. In proceedings of VEE 2014.
>>
>>
>> On Sat, May 16, 2015 at 9:14 PM, Elazar Leibovich <elazarl at gmail.com>
>> wrote:
>>
>>> The question of whether to use a global malloc function, or to use a
>>> function pointer is orthogonal to my question.
>>>
>>> My question is, should I support the case of malloc failure. On one
>>> hand, it complicates the API significantly, but on the other hand it might
>>> be useful for some use cases.
>>>
>>> It's pretty obvious to me that in a modern Linux userspace program,
>>> supporting malloc failure does not worth the trouble. But are there other
>>> use cases where it's vital?
>>>
>>> Another clarification, my code would never have abort. What I was
>>> saying, that the malloc could simply abort current task, if it does not
>>> have memory.
>>>
>>> As a side note, In my experience, it is sometimes useful to use
>>> preallocated "memory pools"[0]. Letting the user choose memory allocator is
>>> also useful when using it in the kernel, since otherwise the library simply
>>> won't compile. See for example protobuf-c which receives an allocator in
>>> its functions,
>>> https://github.com/protobuf-c/protobuf-c/blob/master/protobuf-c/protobuf-c.c#L2019
>>>
>>>
>>> [0]
>>> http://eli.thegreenplace.net/2008/10/17/memmgr-a-fixed-pool-memory-allocator
>>>
>>> On Fri, May 15, 2015 at 9:00 PM, Baruch Even <baruch at ev-en.org> wrote:
>>>
>>>> I would question the need to abstract away the memory allocations of
>>>> your library compared to everything else. If someone cares enough about it
>>>> he can replace malloc and free completely to use a different allocation
>>>> scheme.
>>>>
>>>> In most cases I've cared about memory allocations I just wanted none of
>>>> them at all and only wanted intrusive data structures and just running the
>>>> system with a fixed memory allocation from the start to the end. It's not
>>>> always possible in a generic library though..
>>>>
>>>> If you are writing a library you should never abort inside it, that
>>>> would be very annoying to the user. Give him a null and let him crash or
>>>> handle it as he sees fit.
>>>>
>>>> Baruch
>>>>
>>>> On Fri, May 15, 2015 at 5:47 PM, Elazar Leibovich <elazarl at gmail.com>
>>>> wrote:
>>>>
>>>>> I'm writing a small C library, that I want to open source.
>>>>>
>>>>> I want them to be usable for embedded environment, where memory
>>>>> allocation must be controlled.
>>>>>
>>>>> Hence, I abstracted away calls to malloc/realloc, and replaced them
>>>>> with
>>>>>
>>>>> struct mem_pool {
>>>>>     void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
>>>>> };
>>>>>
>>>>> User would implement
>>>>>
>>>>> struct my_mem_pool {
>>>>>     struct mem_pool pool;
>>>>>     ...
>>>>> };
>>>>>
>>>>> struct my_mem_pool pool = { { my_alloc_func }, ...);
>>>>>
>>>>> I've had to design question I'm interested with:
>>>>>
>>>>> 1) Should I support both malloc and realloc?
>>>>>
>>>>> I think the performance benefits of supporting malloc instead of
>>>>> realloc(NULL) are negligible, and not worth complicating the interface.
>>>>>
>>>>> 2) Should the memory pool be allowed to fail?
>>>>>
>>>>> In typical Linux system, where memory overcommit is allowed, checking
>>>>> malloc return value provides little benefit. But is it the same for
>>>>> embedded system?
>>>>>
>>>>> My feeling is, embedded system should predict the memory usage for
>>>>> each input size, and avoid processing input which is too large.
>>>>>
>>>>> For example, stack overflow error can never be handled, and one is
>>>>> expected to calculate the longest stack length for any input and make sure
>>>>> he wouldn't overflow.
>>>>>
>>>>> So I think it's still reasonable never to report allocation failure,
>>>>> and to expect the memory allocator to raise the relevant
>>>>> abort/panic/exception in such a case.
>>>>>
>>>>> But I'll be happy to hear other considerations I missed.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> _______________________________________________
>>>>> Linux-il mailing list
>>>>> Linux-il at cs.huji.ac.il
>>>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Linux-il mailing list
>>> Linux-il at cs.huji.ac.il
>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>
>>>
>>
>>
>> --
>> Orna Agmon Ben-Yehuda.
>> http://ladypine.org
>>
>
>


-- 
Orna Agmon Ben-Yehuda.
http://ladypine.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150517/cbe43271/attachment-0001.html>

From pub at goldshmidt.org  Sun May 17 22:39:00 2015
From: pub at goldshmidt.org (Oleg Goldshmidt)
Date: Sun, 17 May 2015 22:39:00 +0300
Subject: [somewhat OT] casting to unsigned [Was: Memory pool interface design]
In-Reply-To: <87k2w72g20.fsf@goldshmidt.org>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <87oalk2s4i.fsf@goldshmidt.org>
 <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
 <87k2w72g20.fsf@goldshmidt.org>
Message-ID: <87fv6v2duz.fsf_-_@goldshmidt.org>


In the hope to amuse at least some of you...

Oleg Goldshmidt <pub at goldshmidt.org> writes:

> So you've been lucky so far. At some point you will inevitably run into
> client code that occasionally does something stupid like passing a
> signed integer as size. Trust me, when that happens the size parameter
> usually turns out to be -6. You will have no control over it.

I sent this and tried to figure out what had made me write -6 and not -5
or -7. This:

http://translate.google.com/translate?sl=sv&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.svd.se%2Fnaringsliv%2Fnyheter%2Fsverige%2Fmonsterorder-stoppade-borsen_7708362.svd&act=url

Brief explanation not in the newspaper: the Stockholm stock exchange
crashed horribly in 2012.  From the screenshot fragment shown it seems
pretty obvious what happened. Someone probably tried to short sell 6
OMSX30 (main Swedish stock index) futures contracts, which was
represented as buying -6 of them (or maybe it was a lack of input
validation), and somewhere along the way the order size was cast to
unsigned int. At which point it became clear that no one could buy 131
times the Swedish GDP in one go.

No, malloc probably was not involved. There was, however, a request for
too much of an abundant, but still limited, resource - quite similar.

I was definitely not involved.

The result demonstrates the difference between an uncontrolled crash and
proper error handling that could reject a clearly erroneous order and
keep the exchange operational.

-- 
Oleg Goldshmidt | pub at goldshmidt.org


From d.s at daniel.shahaf.name  Mon May 18 02:37:31 2015
From: d.s at daniel.shahaf.name (Daniel Shahaf)
Date: Sun, 17 May 2015 23:37:31 +0000
Subject: Memory pool interface design
In-Reply-To: <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <87oalk2s4i.fsf@goldshmidt.org>
 <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
Message-ID: <20150517233731.GE2214@tarsus.local2>

Elazar Leibovich wrote on Sun, May 17, 2015 at 00:04:49 +0300:
> A concrete example, a "regular" read_line function
> 
> char *read_line(struct reader *r) { char *rv = malloc(len); read_to(rv);
> return rv; }
...
> Our read_line example would now look like
> 
> struct error read_line(struct reader *r, char **line);
> 
> And users would have to check error at each invocation.
> 
> I think I can avoid that. What do I intend to do?

Another option is to signal error out-of-band ? via some thread-global
variable or function ? and require API users to check that out-of-band
channel after each call:

    line = read_line()
    if (line == NULL || read_line_error())
        /* ... */ ;

For example:
https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Occurred

Daniel


From elazarl at gmail.com  Mon May 18 05:44:16 2015
From: elazarl at gmail.com (Elazar Leibovich)
Date: Mon, 18 May 2015 05:44:16 +0300
Subject: Memory pool interface design
In-Reply-To: <87k2w72g20.fsf@goldshmidt.org>
References: <CAHNTFm+UHqB0-WLzE_AfVBMMY4VDtEuaMahrt+hKmy9sOt5LZA@mail.gmail.com>
 <CAC9+anJVqShgV9a0ynCh5Vw31in9=fFXddfce6Vbo1pDMHvBnw@mail.gmail.com>
 <CAHNTFmLP77CjQa_8vivL5OiA_Yh0-iDYiVqNsqpV1aALz976pg@mail.gmail.com>
 <87oalk2s4i.fsf@goldshmidt.org>
 <CAHNTFmL4DzStdzHq4+ntaWeEzZ-_J2NKbZfLM1a5w13th_1qEg@mail.gmail.com>
 <87k2w72g20.fsf@goldshmidt.org>
Message-ID: <CAHNTFm+1zk-qiH8fxLG8V414tuH5DeSJjRg-DnY_1f3oAVYv_Q@mail.gmail.com>

What are other practical use cases where malloc returns NULL.

You mentioned programmer error.
I second, and mention restricted environment where admin ulimits your
virtual memory.

I'll be happy to hear more.

On Sun, May 17, 2015 at 9:51 PM, Oleg Goldshmidt <pub at goldshmidt.org> wrote:

> Elazar Leibovich <elazarl at gmail.com> writes:
>
> > Regarding 5-6. What I'm saying is, seeing malloc returning NULL in
> > production is very rare.
>
> Hope dies last.. ;-)
>
> > I personally never seen that.
>
> So you've been lucky so far. At some point you will inevitably run into
> client code that occasionally does something stupid like passing a
> signed integer as size. Trust me, when that happens the size parameter
> usually turns out to be -6. You will have no control over it.
>
> > I think that the OOM killer would wreck havoc to the system before it
> > would happen,
>
> Why do you assume that? How *can* you assume that given that OOM
> policies can be configured (at runtime)?
>
> Apart from everything else, why do you assume that malloc only fails
> when there is not enough memory?
>
> And if you allow - nay, require! - that the user specifies a custom
> allocator, how do you know *that* won't fail for some weird (or
> perfectly logical, as the case may be) reason?
>
> > hence, crashing when malloc returns NULL is a reasonable behavior.
>
> For a non-critical single process application under very special
> circumstances - maybe. What if the crash happens while client code is
> tweaking some shared memory, holding a lock or some other resource
> (where a crash would leave some data your library does not control in an
> inconsistent state that will cause problems for other processes or after
> restart), or in general needs to do some cleanup / bookkeeping / logging
> (to tell the user what happened) before dying - how can you possibly
> call hard crash "reasonable behaviour"?
>
> > Regarding 7, this does not complicate the allocation API, it
> > complicates my API, since I'll have functions that cannot fail,
> > generally speaking, but allocates memory.
>
> This implies that you need to handle allocation (and all other) errors
> inside such functions to provide the "no exceptions" guarantee. Your
> options, in order of increased sophistication (you can actually do this
> in stages and hope to get feedback rather than being ignored):
>
> 1. Decide how and do that - that's a policy. See if this is attractve to
>    your users. Hope to get emails saying "I wish you didn't abort."
>
>    [If you get such emails feel very proud - someone cares enough, you
>    probably did a very good job on everything else.]
>
> 2. Provide several different policies and a configuration mechanism to
>    choose - see if this is more successful than #1 above. Hope to get
>    emails saying "I wish you would add this other policy."
>
> 3. Provide a callback hook so that a user can implement and register a
>    handler - effectively, support custom policies.
>
>    By the time you get to this stage you may realize that you may just
>    as well return a status code and let the user handle the
>    condition. I expect this to be easier for users than registering
>    callbacks. It will also be more flexible since different policies may
>    be applied in different places in a single client program.
>
> > Those would have to return error, and the user would have to check the
> > error.
>
> As both Guy and I said before, this is the proper behaviour for a
> general purpose library.
>
> --
> Oleg Goldshmidt | pub at goldshmidt.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150518/699a09a0/attachment.html>

From shlomo.solomon at gmail.com  Mon May 18 09:24:43 2015
From: shlomo.solomon at gmail.com (Shlomo Solomon)
Date: Mon, 18 May 2015 09:24:43 +0300
Subject: TV tuner or video capture card recommendation
In-Reply-To: <20150511115924.34d94d1a@shlomo1.solomon>
References: <20150511115924.34d94d1a@shlomo1.solomon>
Message-ID: <20150518092443.39b08b77@shlomo1.solomon>

I discovered that the EasyCAP USB card I bought on eBay quite a while
ago is now supported in the Linux kernel, but don't know how to tell
TVtime to use the usbtv device instead of the saa7134.


Below is info about my existing saa7134 PCI card (which TVtime does
recognize) and the new usbtv EasyCAP. 




[solomon at shlomo1 /]$ sudo lsmod | grep saa saa7134
186437  1 tveeprom               21216  1 saa7134
videobuf_dma_sg        19262  1 saa7134 videobuf_core          26023  2
videobuf_dma_sg,saa7134 rc_core                28042  1 saa7134
v4l2_common            15265  3 tuner,usbtv,saa7134
videodev              148922  6
tuner,usbtv,saa7134,v4l2_common,videobuf2_core i2c_core
41150  11
drm,i915,i2c_i801,tuner,saa7134,drm_kms_helper,i2c_algo_bit,v4l2_common,tveeprom,tuner_simple,videodev

[solomon at shlomo1 /]$ sudo lsmod | grep usbtv
usbtv                  17919  0 
videobuf2_vmalloc      13216  1 usbtv
videobuf2_core         41043  1 usbtv
v4l2_common            15265  3 tuner,usbtv,saa7134
videodev              148922  5
tuner,usbtv,saa7134,v4l2_common,videobuf2_core usbcore
230079  8
btusb,usblp,usbtv,usb_storage,ehci_hcd,ehci_pci,usbhid,xhci_hcd



[solomon at shlomo1 /]$ dmesg|grep saa
[    5.853089] saa7130/34: v4l2 driver version 0, 2, 17 loaded
[    5.853237] saa7130[0]: found at 0000:03:00.0, rev: 1, irq: 19,
latency: 32, mmio: 0xf0400000 [    5.853243] saa7130[0]: subsystem:
1131:0000, board: 10MOONS PCI TV CAPTURE CARD [card=21,insmod option]
[    5.853255] saa7130[0]: board init: gpio is 38500 [    5.953730]
saa7130[0]: Huh, no eeprom present (err=-5)? [    6.119592] saa7130[0]:
registered device video0 [v4l2] [    6.119650] saa7130[0]: registered
device vbi0 [    6.119687] saa7130[0]: registered device radio0
[  422.329728]  saa7134 tveeprom videobuf_dma_sg videobuf_core rc_core
processor v4l2_common videodev media nfsd nvram auth_rpcgss
oid_registry kvm_intel nfs_acl lockd sunrpc kvm ipv6 autofs4 xhci_hcd
ehci_pci ehci_hcd sr_mod usbcore usb_common i915 video button
i2c_algo_bit drm_kms_helper drm i2c_core [  422.329767]
[<ffffffffa03eff3b>] video_release+0x27b/0x310 [saa7134]
[  436.230967]  saa7134 tveeprom videobuf_dma_sg videobuf_core rc_core
processor v4l2_common videodev media nfsd nvram auth_rpcgss
oid_registry kvm_intel nfs_acl lockd sunrpc kvm ipv6 autofs4 xhci_hcd
ehci_pci ehci_hcd sr_mod usbcore usb_common i915 video button
i2c_algo_bit drm_kms_helper drm i2c_core [  436.231001]
[<ffffffffa03eff3b>] video_release+0x27b/0x310 [saa7134]
[  516.415357]  saa7134 tveeprom videobuf_dma_sg videobuf_core rc_core
processor v4l2_common videodev media nfsd nvram auth_rpcgss
oid_registry kvm_intel nfs_acl lockd sunrpc kvm ipv6 autofs4 xhci_hcd
ehci_pci ehci_hcd sr_mod usbcore usb_common i915 video button
i2c_algo_bit drm_kms_helper drm i2c_core [  516.415394]
[<ffffffffa03eff3b>] video_release+0x27b/0x310 [saa7134]


[solomon at shlomo1 /]$ dmesg|grep usbtv [    3.198700] usb 3-2: Product:
usbtv007 [    8.583562] usbtv 3-2:1.0: Fushicai USBTV007 Video Grabber
[    8.583588] usbcore: registered new interface driver usbtv
[  422.329699] Modules linked in: rfcomm arc4 ecb md4 nls_utf8 cifs
af_packet bnep vboxnetadp(O) vboxnetflt(O) vboxdrv(O) usbtv
videobuf2_vmalloc videobuf2_memops videobuf2_core btusb bluetooth
6lowpan_iphc rfkill hid_generic usbhid usb_storage usblp hid
x86_pkg_temp_thermal intel_powerclamp coretemp reiserfs
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd
iTCO_wdt iTCO_vendor_support cpufreq_ondemand cpufreq_conservative
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi e1000e
cpufreq_powersave ptp snd_hda_intel snd_hda_codec tuner_simple
tuner_types shpchp microcode pps_core lpc_ich serio_raw snd_hwdep
snd_pcm tuner thermal fan snd_timer snd i2c_i801 mei_me mei evdev
soundcore tpm_infineon tpm_tis tpm battery [  436.230938] Modules
linked in: rfcomm arc4 ecb md4 nls_utf8 cifs af_packet bnep
vboxnetadp(O) vboxnetflt(O) vboxdrv(O) usbtv videobuf2_vmalloc
videobuf2_memops videobuf2_core btusb bluetooth 6lowpan_iphc rfkill
hid_generic usbhid usb_storage usblp hid x86_pkg_temp_thermal
intel_powerclamp coretemp reiserfs crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support
cpufreq_ondemand cpufreq_conservative snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi e1000e cpufreq_powersave ptp
snd_hda_intel snd_hda_codec tuner_simple tuner_types shpchp microcode
pps_core lpc_ich serio_raw snd_hwdep snd_pcm tuner thermal fan
snd_timer snd i2c_i801 mei_me mei evdev soundcore tpm_infineon tpm_tis
tpm battery [  516.415320] Modules linked in: rfcomm arc4 ecb md4
nls_utf8 cifs af_packet bnep vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
usbtv videobuf2_vmalloc videobuf2_memops videobuf2_core btusb bluetooth
6lowpan_iphc rfkill hid_generic usbhid usb_storage usblp hid
x86_pkg_temp_thermal intel_powerclamp coretemp reiserfs
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd
iTCO_wdt iTCO_vendor_support cpufreq_ondemand cpufreq_conservative
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi e1000e
cpufreq_powersave ptp snd_hda_intel snd_hda_codec tuner_simple
tuner_types shpchp microcode pps_core lpc_ich serio_raw snd_hwdep
snd_pcm tuner thermal fan snd_timer snd i2c_i801 mei_me mei evdev
soundcore tpm_infineon tpm_tis tpm battery [solomon at shlomo1 /]$ 






On Mon, 11 May 2015 11:59:24 +0300
Shlomo Solomon <shlomo at the-solomons.net> wrote:

> I have a VERY old no-name PCI TV tuner which has started to cause
> problems (choppy video and no sound). Until recently it worked fine
> and I could watch TV using TVtime or XawTV. I honestly don't know if
> the problem is software (maybe caused by an upgrade?) or hardware (a
> bad cable or connection or the card itself). But because it's so old,
> it's probably not worth saving.
> 
> There are lots of articles on the net about hardware, drivers,
> installation, what works or doesn't, etc. But I'm looking for
> firsthand experience. For example, I've seen various articles about
> EasyCap or EZCap working/not working. I do know that there are
> several similar pieces of hardware using different chipsets, so it's
> hard to depend on these articles. In fact, about a year ago I bought
> a card on eBay but had no luck getting it to work.
> 
> My needs are really simple:
> 1 - USB connection
> 2 - can capture analog video and audio from a YES "MEMIR"
> 3 - works on Mageia and/or Raspberry PI Raspbian
> 4 - preferably work with TVtime, but any other workable software is OK
> 
> 



-- 
Shlomo Solomon
http://the-solomons.net
Sent by Claws Mail 3.11.1 - KDE 4.12.15 - LINUX Mageia 4



From slitt at troubleshooters.com  Tue May 19 04:37:42 2015
From: slitt at troubleshooters.com (Steve Litt)
Date: Mon, 18 May 2015 21:37:42 -0400
Subject: Pacman Basic Essentials Cheatsheet
Message-ID: <20150518213742.24a41b9e@mydesq2.domain.cxm>

Hi all,

For any of you who are new users of Arch or Manjaro, check out my new
Pacman Basic Essentials Cheatsheet at
http://www.troubleshooters.com/linux/pacman_cheatsheet.htm . It gives
quick lookups on a few of the commands you use constantly.

Enjoy!

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz


From shlomif at gmail.com  Tue May 19 09:34:33 2015
From: shlomif at gmail.com (Shlomi Fish)
Date: Tue, 19 May 2015 09:34:33 +0300
Subject: Pacman Basic Essentials Cheatsheet
In-Reply-To: <20150518213742.24a41b9e@mydesq2.domain.cxm>
References: <20150518213742.24a41b9e@mydesq2.domain.cxm>
Message-ID: <CANy4znXuwGar+uLPHhefNGnzSbqM6iwnAQJbT+vv1ZZ72g+97Q@mail.gmail.com>

On Tue, May 19, 2015 at 4:37 AM, Steve Litt <slitt at troubleshooters.com>
wrote:

> Hi all,
>
> For any of you who are new users of Arch or Manjaro, check out my new
> Pacman Basic Essentials Cheatsheet at
> http://www.troubleshooters.com/linux/pacman_cheatsheet.htm . It gives
> quick lookups on a few of the commands you use constantly.
>
>
Thanks for sharing that, Steve!

Regards,

-- Shlomi Fish


> Enjoy!
>
> SteveT
>
> Steve Litt
> May 2015 featured book: Quit Joblessness: Start Your Own Business
> http://www.troubleshooters.com/startbiz
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>



-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Chuck Norris helps the gods that help themselves.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150519/27c8522e/attachment-0001.html>

From shlomif at gmail.com  Tue May 19 09:45:32 2015
From: shlomif at gmail.com (Shlomi Fish)
Date: Tue, 19 May 2015 09:45:32 +0300
Subject: Mageia Linux mirror on http://mirror.isoc.org.il/content.html
In-Reply-To: <CAEsznC5MsSdRXiOiV7CmHY0KefVcXMENE=U17z_G63SidB-1ow@mail.gmail.com>
References: <CANy4znWBbTibbrXjHp3kPAZGSgKcBcM7_ZOsBgW4-bdn_W5PZQ@mail.gmail.com>
 <CAEsznC55_XhUjYf8PR+LNSmGOKyViAhCciP3f2p0kRhHjkqQ9Q@mail.gmail.com>
 <CAEsznC7JDq1uoznXibatvTzM4QG=MhHdK4timMyyW-BLrHSyfQ@mail.gmail.com>
 <CANy4znXpHU2dLLMr74SwtSCrVhVXkb=cEuoa9+OjD0cLHGh7nw@mail.gmail.com>
 <CAEsznC5MsSdRXiOiV7CmHY0KefVcXMENE=U17z_G63SidB-1ow@mail.gmail.com>
Message-ID: <CANy4znXeQfwUs0j=4CX7jGAN2B4WEL7EpaamWmF2jnE7Orrxrg@mail.gmail.com>

Hi Lior,

On Sat, May 9, 2015 at 12:05 PM, Lior Kaplan <kaplanlior at gmail.com> wrote:

> On Sat, May 9, 2015 at 12:01 PM, Shlomi Fish <shlomif at gmail.com> wrote:
>
>> Hi Lior,
>>
>> On Fri, May 1, 2015 at 8:50 AM, Lior Kaplan <kaplanlior at gmail.com> wrote:
>>
>>> So it seems the initial sync takes much longer.
>>>
>>> I expect another 24 hours.
>>>
>>>
>> Has the mirror been synced already? Can we start using it now?
>>
>> Yes, go ahead.
>
>
Done. Thanks!

Another thing I noticed is that the pages
http://mirror.isoc.org.il/content.html and
http://mirror.isoc.org.il/definitions.html still refer to Mandriva rather
than Mageia, and there are also mentions of Kazit , Kinneret and Ehad on
http://mirror.isoc.org.il/content.html - I doubt they are still relevant.
Can these things be corrected? Where can one find the sources of the pages
of http://mirror.isoc.org.il/ ?

Regards,

-- Shlomi Fish



-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Chuck Norris helps the gods that help themselves.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150519/7b48c3af/attachment.html>

From david at davidsconsultants.com  Thu May 21 13:22:00 2015
From: david at davidsconsultants.com (David Suna)
Date: Thu, 21 May 2015 13:22:00 +0300
Subject: Debian mirror problem
Message-ID: <555DB1C8.5040902@davidsconsultants.com>

I am trying to do an apt-get update on my Debian system and I am getting 
the following error:
E: Release file for 
http://debian.co.il/debian/dists/jessie-updates/InRelease is expired 
(invalid since 19h 6min 28s). Updates for this repository will not be 
applied.

I could change which mirror I use but is there someone on the list who 
can bring this to the attention of the right person to get it fixed?

Thanks,

-- 
David Suna
david at davidsconsultants.com



From kaplanlior at gmail.com  Thu May 21 13:30:18 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Thu, 21 May 2015 13:30:18 +0300
Subject: Debian mirror problem
In-Reply-To: <555DB1C8.5040902@davidsconsultants.com>
References: <555DB1C8.5040902@davidsconsultants.com>
Message-ID: <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>

mirror.isoc.org.il is updated 4 times a day for Debian...

(Yes, I'm biased (: )

Kaplan

On Thu, May 21, 2015 at 1:22 PM, David Suna <david at davidsconsultants.com>
wrote:

> I am trying to do an apt-get update on my Debian system and I am getting
> the following error:
> E: Release file for
> http://debian.co.il/debian/dists/jessie-updates/InRelease is expired
> (invalid since 19h 6min 28s). Updates for this repository will not be
> applied.
>
> I could change which mirror I use but is there someone on the list who can
> bring this to the attention of the right person to get it fixed?
>
> Thanks,
>
> --
> David Suna
> david at davidsconsultants.com
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150521/def1eca7/attachment.html>

From david at davidsconsultants.com  Thu May 21 13:39:25 2015
From: david at davidsconsultants.com (David Suna)
Date: Thu, 21 May 2015 13:39:25 +0300
Subject: Debian mirror problem
In-Reply-To: <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
Message-ID: <555DB5DD.8020908@davidsconsultants.com>

An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150521/4e6cf6ee/attachment.html>

From kaplanlior at gmail.com  Thu May 21 14:30:23 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Thu, 21 May 2015 14:30:23 +0300
Subject: Debian mirror problem
In-Reply-To: <555DB5DD.8020908@davidsconsultants.com>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
 <555DB5DD.8020908@davidsconsultants.com>
Message-ID: <CAEsznC7FrR2PE5VE3PFu5kSteeEtM5gFh-zQ4qXHjdc2xQ99pQ@mail.gmail.com>

Yes.... that's why I refereed you to another mirror.

On Thu, May 21, 2015 at 1:39 PM, David Suna <david at davidsconsultants.com>
wrote:

>  If there is a release file that expired 19 hours ago does that indicate
> that there is a problem with the updates?
>
>
> On 05/21/2015 01:30 PM, Lior Kaplan wrote:
>
>  mirror.isoc.org.il is updated 4 times a day for Debian...
>
>  (Yes, I'm biased (: )
>
>  Kaplan
>
> On Thu, May 21, 2015 at 1:22 PM, David Suna <david at davidsconsultants.com>
> wrote:
>
>> I am trying to do an apt-get update on my Debian system and I am getting
>> the following error:
>> E: Release file for
>> http://debian.co.il/debian/dists/jessie-updates/InRelease is expired
>> (invalid since 19h 6min 28s). Updates for this repository will not be
>> applied.
>>
>> I could change which mirror I use but is there someone on the list who
>> can bring this to the attention of the right person to get it fixed?
>>
>> Thanks,
>>
>> --
>> David Suna
>> david at davidsconsultants.com
>>
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>
>
> --
> David Sunadavid at davidsconsultants.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150521/87c0a091/attachment.html>

From efraim at flashner.co.il  Thu May 21 15:10:41 2015
From: efraim at flashner.co.il (Efraim Flashner)
Date: Thu, 21 May 2015 15:10:41 +0300
Subject: Debian mirror problem
In-Reply-To: <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
Message-ID: <20150521151041.07b54c95@debian-netbook>

On Thu, 21 May 2015 13:30:18 +0300
Lior Kaplan <kaplanlior at gmail.com> wrote:

> mirror.isoc.org.il is updated 4 times a day for Debian...
>
> (Yes, I'm biased (: )

mirror.isoc.org.il doesn't have armhf packages, but debian.co.il does
 
> Kaplan
> 
> On Thu, May 21, 2015 at 1:22 PM, David Suna <david at davidsconsultants.com>
> wrote:
> 
> > I am trying to do an apt-get update on my Debian system and I am getting
> > the following error:
> > E: Release file for
> > http://debian.co.il/debian/dists/jessie-updates/InRelease is expired
> > (invalid since 19h 6min 28s). Updates for this repository will not be
> > applied.
> >
> > I could change which mirror I use but is there someone on the list who can
> > bring this to the attention of the right person to get it fixed?
> >
> > Thanks,
> >
> > --
> > David Suna
> > david at davidsconsultants.com
> >
> >
> > _______________________________________________
> > Linux-il mailing list
> > Linux-il at cs.huji.ac.il
> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
> >



-- 
Efraim Flashner   <efraim at flashner.co.il>   ????? ?????
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150521/e9151ecc/attachment.sig>

From kaplanlior at gmail.com  Thu May 21 15:47:28 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Thu, 21 May 2015 15:47:28 +0300
Subject: Debian mirror problem
In-Reply-To: <20150521151041.07b54c95@debian-netbook>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
 <20150521151041.07b54c95@debian-netbook>
Message-ID: <CAEsznC60DvE-dcxH4c8m8Kee7xbQy1XU2Z9M3_0jR682uVOeFg@mail.gmail.com>

On Thu, May 21, 2015 at 3:10 PM, Efraim Flashner <efraim at flashner.co.il>
wrote:

> On Thu, 21 May 2015 13:30:18 +0300
> Lior Kaplan <kaplanlior at gmail.com> wrote:
>
> > mirror.isoc.org.il is updated 4 times a day for Debian...
> >
> > (Yes, I'm biased (: )
>
> mirror.isoc.org.il doesn't have armhf packages, but debian.co.il does


Good to know. I think no one asked for these packages.

(Maybe because others provided them).

Kaplan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150521/90307d28/attachment-0001.html>

From tzafrir at cohens.org.il  Thu May 21 15:57:28 2015
From: tzafrir at cohens.org.il (Tzafrir Cohen)
Date: Thu, 21 May 2015 14:57:28 +0200
Subject: Debian mirror problem
In-Reply-To: <CAEsznC60DvE-dcxH4c8m8Kee7xbQy1XU2Z9M3_0jR682uVOeFg@mail.gmail.com>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
 <20150521151041.07b54c95@debian-netbook>
 <CAEsznC60DvE-dcxH4c8m8Kee7xbQy1XU2Z9M3_0jR682uVOeFg@mail.gmail.com>
Message-ID: <20150521125727.GB20529@lemon.cohens.org.il>

On Thu, May 21, 2015 at 03:47:28PM +0300, Lior Kaplan wrote:
> On Thu, May 21, 2015 at 3:10 PM, Efraim Flashner <efraim at flashner.co.il>
> wrote:
> 
> > On Thu, 21 May 2015 13:30:18 +0300
> > Lior Kaplan <kaplanlior at gmail.com> wrote:
> >
> > > mirror.isoc.org.il is updated 4 times a day for Debian...
> > >
> > > (Yes, I'm biased (: )
> >
> > mirror.isoc.org.il doesn't have armhf packages, but debian.co.il does
> 
> 
> Good to know. I think no one asked for these packages.

/me asks.

> 
> (Maybe because others provided them).

I switched to ftp.de.debian.org.

-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend


From kaplanlior at gmail.com  Fri May 22 11:41:01 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Fri, 22 May 2015 11:41:01 +0300
Subject: Mageia Linux mirror on http://mirror.isoc.org.il/content.html
In-Reply-To: <CANy4znXeQfwUs0j=4CX7jGAN2B4WEL7EpaamWmF2jnE7Orrxrg@mail.gmail.com>
References: <CANy4znWBbTibbrXjHp3kPAZGSgKcBcM7_ZOsBgW4-bdn_W5PZQ@mail.gmail.com>
 <CAEsznC55_XhUjYf8PR+LNSmGOKyViAhCciP3f2p0kRhHjkqQ9Q@mail.gmail.com>
 <CAEsznC7JDq1uoznXibatvTzM4QG=MhHdK4timMyyW-BLrHSyfQ@mail.gmail.com>
 <CANy4znXpHU2dLLMr74SwtSCrVhVXkb=cEuoa9+OjD0cLHGh7nw@mail.gmail.com>
 <CAEsznC5MsSdRXiOiV7CmHY0KefVcXMENE=U17z_G63SidB-1ow@mail.gmail.com>
 <CANy4znXeQfwUs0j=4CX7jGAN2B4WEL7EpaamWmF2jnE7Orrxrg@mail.gmail.com>
Message-ID: <CAEsznC4hNtv+iFghM-XAE8hfQjXXnbWOt1J7VbUPGdLjcCQvTQ@mail.gmail.com>

On Tue, May 19, 2015 at 9:45 AM, Shlomi Fish <shlomif at gmail.com> wrote:

> Hi Lior,
>
> On Sat, May 9, 2015 at 12:05 PM, Lior Kaplan <kaplanlior at gmail.com> wrote:
>
>> On Sat, May 9, 2015 at 12:01 PM, Shlomi Fish <shlomif at gmail.com> wrote:
>>
>>> Hi Lior,
>>>
>>> On Fri, May 1, 2015 at 8:50 AM, Lior Kaplan <kaplanlior at gmail.com>
>>> wrote:
>>>
>>>> So it seems the initial sync takes much longer.
>>>>
>>>> I expect another 24 hours.
>>>>
>>>>
>>> Has the mirror been synced already? Can we start using it now?
>>>
>>> Yes, go ahead.
>>
>>
> Done. Thanks!
>
> Another thing I noticed is that the pages
> http://mirror.isoc.org.il/content.html and
> http://mirror.isoc.org.il/definitions.html still refer to Mandriva rather
> than Mageia, and there are also mentions of Kazit , Kinneret and Ehad on
> http://mirror.isoc.org.il/content.html - I doubt they are still relevant.
> Can these things be corrected? Where can one find the sources of the pages
> of http://mirror.isoc.org.il/ ?
>

That's why I wrote: "????? ?????? ?? ???? ??? ????? ????? ????? "???? ????
<http://wiki.hamakor.org.il/index.php/%D7%90%D7%AA%D7%A8%D7%99_%D7%9E%D7%A8%D7%90%D7%94#.D7.90.D7.99.D7.92.D7.95.D7.93_.D7.94.D7.90.D7.99.D7.A0.D7.98.D7.A8.D7.A0.D7.98>"
?????? ?? ????? ?????."

Also, we still hold the mirror for Kazit, although it's ancient.

I'll drop the mandriva instructions.

Kaplan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150522/3c2f2922/attachment.html>

From slitt at troubleshooters.com  Sun May 24 01:31:03 2015
From: slitt at troubleshooters.com (Steve Litt)
Date: Sat, 23 May 2015 18:31:03 -0400
Subject: New Qemu and VirtualBox docs for Linux
Message-ID: <20150523183103.774922ad@mydesq2.domain.cxm>

Hi all,

As part of my DIY Linux push, I've completed documents on running and
modifying Linux distros on Qemu and VirtualBox. There are many
advantages, including convenience and speed (on hardware with hardware
VM assist), and not collecting a vast pile of labeled hard disks for
the various experiments.

Here are the articles:

* http://troubleshooters.com/linux/diy/virtualbox.htm

* http://troubleshooters.com/linux/diy/qemu.htm

I hope you enjoy them.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz


From amos.shapira at gmail.com  Sun May 24 03:36:22 2015
From: amos.shapira at gmail.com (Amos Shapira)
Date: Sun, 24 May 2015 10:36:22 +1000
Subject: New Qemu and VirtualBox docs for Linux
In-Reply-To: <20150523183103.774922ad@mydesq2.domain.cxm>
References: <20150523183103.774922ad@mydesq2.domain.cxm>
Message-ID: <CAF9n_WWkQmuSns5phy7xPuDPMYsU=ToKTYrp1VYFOpMEk0SFKA@mail.gmail.com>

Hi Steve,

I only read the first articles you sent a few weeks ago and they were
pretty good. Well done.

In relation to the latest installments - I'd like to suggest looking at
Vagrant and Packer too. I find that configuring everything in a text file
(basically, a Ruby script) is an extremely powerful way to document
repeatable and automated steps.

Cheers,

--Amos

On 24 May 2015 at 08:31, Steve Litt <slitt at troubleshooters.com> wrote:

> Hi all,
>
> As part of my DIY Linux push, I've completed documents on running and
> modifying Linux distros on Qemu and VirtualBox. There are many
> advantages, including convenience and speed (on hardware with hardware
> VM assist), and not collecting a vast pile of labeled hard disks for
> the various experiments.
>
> Here are the articles:
>
> * http://troubleshooters.com/linux/diy/virtualbox.htm
>
> * http://troubleshooters.com/linux/diy/qemu.htm
>
> I hope you enjoy them.
>
> SteveT
>
> Steve Litt
> May 2015 featured book: Quit Joblessness: Start Your Own Business
> http://www.troubleshooters.com/startbiz
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>



-- 
<http://au.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150524/05caf467/attachment.html>

From beni.cherniavsky at gmail.com  Tue May 26 15:17:29 2015
From: beni.cherniavsky at gmail.com (Beni Cherniavsky-Paskin)
Date: Tue, 26 May 2015 15:17:29 +0300
Subject: OT: Xiaomi phones
In-Reply-To: <CAJzkJxEZvn9WF_5bfpinOnddqxwFd0Z--GXRSOhxU+FQkthXHw@mail.gmail.com>
References: <CAJzkJxEZvn9WF_5bfpinOnddqxwFd0Z--GXRSOhxU+FQkthXHw@mail.gmail.com>
Message-ID: <CALJxeiJEgWTeL_gqFvCRZi_PY7Pe64WwYvewtR-pR4PQK4z3DA@mail.gmail.com>

I recently got a Mi Pad from geekbuying.com.
[can't recommend them.  took several months, perhaps in part because they
declared "$20 value" and I got warning from Israeli customs.
when I rebuked them they pointed to me to a page where that's their
official policy unless asked not to lie...]

270USD (incl. shipping) + 169ILS mas kniya + 233 maam.

Spec-wise, it's similar to Nvidia Shield tablet (Tegra K1) but better 4:3
screen and cheaper.  No stylus though, and no HDMI out.

Use case was 8 month baby [1]; mostly her brother "borrows" it since he
broke his Yoga B8080 tablet.  (Yoga's stand was extremely convenient for a
kid and contained a monstrous battery but alas didn't take the abuse for
long...)

Performance is very smooth.  I haven't tried any high-end gaming yet but
it's supposed to be superb.
I didn't really need such power, simply got tired of several underpowered
hardware and felt like maxing out this time...

Software: Xiaomi ships a heavily customized android 4.4.4.  It somewhat
resembles Apple (as does the hardware design).
There are various thoughtful touches.  I gather their software has a big
enthusiastic following and they are very responsive to fan feedback, but I
don't really have time to enjoy that and I'd rather have stock android if
only to stick with open source.
It comes with Xiaomi's app store, browser etc ? but also with google's Play
Store so getting Chrome etc. was easy.
I'll probably start with more familiar launcher.

I haven't looked into alternate ROMs ? or even rooted yet ? but it seems
easy.
"Xiaomi issues regular Miui rom update for all its devic es. there are
stables roms issued once per month and weekly developer roms. The later is
always rooted and the roms from the link above [http://xiaomi.eu/community/]
are always without unecessary chinese apps and in european languages. "

Unusually, Xiaomi also provides its skin for a lot of phones by other
manufacturers: http://en.miui.com/download.html


Also got protector + a not so good case from eBay, can elaborate.


[1] Whether this is a good idea is very contentious, but as a programmer
I'm determined my kids will, as Jeff Atwood put it, be "issued a regulation
iPad at birth. You know, the best, most complex toy there is: a computer."

2015-04-27 20:06 GMT+03:00 Mord Behar <mordbe0 at gmail.com>:

> Has anybody on this list bought one of Xiaomi's new phones (or tablet)?
> Spec-wise they should be really good, and very cheap. I'm curious about
> use case stories, buying the device, shipping it to Israel, using it,
> upgrading it and so on. Also, what you did when it broke.
> Thanks.
> Mordechai
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150526/815ac722/attachment.html>

From kaplanlior at gmail.com  Wed May 27 11:44:15 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Wed, 27 May 2015 11:44:15 +0300
Subject: Debian mirror problem
In-Reply-To: <20150521125727.GB20529@lemon.cohens.org.il>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
 <20150521151041.07b54c95@debian-netbook>
 <CAEsznC60DvE-dcxH4c8m8Kee7xbQy1XU2Z9M3_0jR682uVOeFg@mail.gmail.com>
 <20150521125727.GB20529@lemon.cohens.org.il>
Message-ID: <CAEsznC5TzutnM3xR_r+b2arcv=Z7XAHQqveXVntt_uXTGXqdbw@mail.gmail.com>

On Thu, May 21, 2015 at 3:57 PM, Tzafrir Cohen <tzafrir at cohens.org.il>
wrote:

> On Thu, May 21, 2015 at 03:47:28PM +0300, Lior Kaplan wrote:
> > On Thu, May 21, 2015 at 3:10 PM, Efraim Flashner <efraim at flashner.co.il>
> > wrote:
> >
> > > On Thu, 21 May 2015 13:30:18 +0300
> > > Lior Kaplan <kaplanlior at gmail.com> wrote:
> > >
> > > > mirror.isoc.org.il is updated 4 times a day for Debian...
> > > >
> > > > (Yes, I'm biased (: )
> > >
> > > mirror.isoc.org.il doesn't have armhf packages, but debian.co.il does
> >
> >
> > Good to know. I think no one asked for these packages.
>
> /me asks.


Adding armhf. I'll let the packages sync first and then add the indexes
(probably during the weekend).

Kaplan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150527/f40aa6f9/attachment-0001.html>

From kaplanlior at gmail.com  Thu May 28 11:15:57 2015
From: kaplanlior at gmail.com (Lior Kaplan)
Date: Thu, 28 May 2015 11:15:57 +0300
Subject: Debian mirror problem
In-Reply-To: <CAEsznC5TzutnM3xR_r+b2arcv=Z7XAHQqveXVntt_uXTGXqdbw@mail.gmail.com>
References: <555DB1C8.5040902@davidsconsultants.com>
 <CAEsznC6aZyTnM8dDaHaRGX4wFq4A_U66WuoghHL3P_902RMh7g@mail.gmail.com>
 <20150521151041.07b54c95@debian-netbook>
 <CAEsznC60DvE-dcxH4c8m8Kee7xbQy1XU2Z9M3_0jR682uVOeFg@mail.gmail.com>
 <20150521125727.GB20529@lemon.cohens.org.il>
 <CAEsznC5TzutnM3xR_r+b2arcv=Z7XAHQqveXVntt_uXTGXqdbw@mail.gmail.com>
Message-ID: <CAEsznC48DX10yTZWitqOC3KWwxedWur4SOV3=AJjFm4ALuPPbQ@mail.gmail.com>

On Wed, May 27, 2015 at 11:44 AM, Lior Kaplan <kaplanlior at gmail.com> wrote:

> On Thu, May 21, 2015 at 3:57 PM, Tzafrir Cohen <tzafrir at cohens.org.il>
> wrote:
>
>> On Thu, May 21, 2015 at 03:47:28PM +0300, Lior Kaplan wrote:
>> > On Thu, May 21, 2015 at 3:10 PM, Efraim Flashner <efraim at flashner.co.il
>> >
>> > wrote:
>> >
>> > > On Thu, 21 May 2015 13:30:18 +0300
>> > > Lior Kaplan <kaplanlior at gmail.com> wrote:
>> > >
>> > > > mirror.isoc.org.il is updated 4 times a day for Debian...
>> > > >
>> > > > (Yes, I'm biased (: )
>> > >
>> > > mirror.isoc.org.il doesn't have armhf packages, but debian.co.il does
>> >
>> >
>> > Good to know. I think no one asked for these packages.
>>
>> /me asks.
>
>
> Adding armhf. I'll let the packages sync first and then add the indexes
> (probably during the weekend).
>

Sync done, indexes updated (available from wheezy and up).

Enjoy,

Kaplan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150528/02c50bae/attachment.html>