About the new grml direction
Hi folks,
as announced on IRC some thoughts about the new grml direction.
For me grml was always an all purpose live cd for text users and zsh addicts. I always knew I could just load a grml a I would have a more or less complete working environment afterwards. On the other hand I was able to just use grml-small if I needed a live cd just for booting and chrooting into the usual environment (i.e. for restoring the bootloader) or use -small as a base for my own customisations.
Unfortunatly these assumptions aren't valid anymore. IMHO it is not a good idea to focus on rescue environments. GRML was known for two things: the great collection of well prepared text tools and their release names. I don't think focussing on release names as the only unique feature is a good idea. There are rescue systems like ten a penny.
Also wasting 350 mb of space on a cd is a (imho) stupid thing.
I want my old grml-small and -full back. And as it seems I am not alone.
It is not my style to just whine. So what do I have to do to get my old grml back? Yeah my time is limited, but anyhow I have to try. I don't want to lose my beloved grml tool.
Alex
P.S. When was the decision of dropping all flavours but this 350 meg flavour done? I didn't mentioned it until the release.
* Alexander Wirt wrote [27.12.11 16:45]:
P.S. When was the decision of dropping all flavours but this 350 meg flavour done? I didn't mentioned it until the release.
It was on the last Grml Developer Meeting - http://ml.grml.org/pipermail/grml-devel/2011-October/000160.html
There was also an announcment in November http://ml.grml.org/pipermail/grml-devel/2011-November/000197.html
* Alexander Wirt wrote [27.12.11 16:45]:
For me grml was always an all purpose live cd for text users and zsh addicts. I always knew I could just load a grml a I would have a more or less complete working environment afterwards.
The problem is we don't have the manpower to do such a release. It was always cumbersome and stressfull for the persons involved in the release.
And the complete work environment was always a problem. Several times questions like these came up:
Q: Does package X make sense on a Live-CD? A: No but people may using Grml as a Dekstop system/work environment…
For me personally it was always unclear what the purpose of Grml was, what's its vision, what belongs on the CD, what does not. And i think with this release it became clear and obvious.
On the other hand I was able to just use grml-small if I needed a live cd just for booting and chrooting into the usual environment (i.e. for restoring the bootloader) or use -small as a base for my own customisations.
Releasing all different kind of flavours like grml-{full,medium,small}{64,32} resulted in six isos, which all had to be tested. And again there were typically not many people involved in testing the releases. It was neither fun nor interesting nor rewarding. It was just a lot of work for nothing really important. And this is not something new.
And what is the reason for using grml-small instead of the new grml-full? USB sticks typically have more then 350mb, if you want to use the ISO image on /boot in combination with grml-rescueboot you can mount a LVM LV over /boot/grml and use that.
That being said, i think that we maybe should/can reintroducde grml-small. Removing packages from a package list should result in less problems than adding new ones. But first we must get rid of grml-small specific hacks (IMHO).
Unfortunatly these assumptions aren't valid anymore. IMHO it is not a good idea to focus on rescue environments. GRML was known for two things: the great collection of well prepared text tools and their release names.
If you look around the internet about discussions for rescue systems, network stuff or other Live-CDs, Grml was never recommended as the first Distribution. Typically only one persons in the threads writing Oh but i like Grml. Thats it. And i personally think it is because Grml was everything and nothing. No area it was especially good at but tried to please everyone.
I don't think focussing on release names as the only unique feature is a good idea. There are rescue systems like ten a penny.
That's the reason I wrote http://blog.grml.org/archives/369-10-reasons-why-you-should-use-Grml-instead...
And it is not only rescue, it is also installation. Thats for example the reason we added rinse to the packagel ist.
Also wasting 350 mb of space on a cd is a (imho) stupid thing.
Wasting 4 GB on a DVD is also a stupid thing… I don't think the free space left on a device should be considered an argument at all. Only if it fits on a specific medium.
I want my old grml-small and -full back. And as it seems I am not alone.
grml-full is the flavour name for the current release. grml-xl is atm the old package list.
If someone steps up regarding grml-xl sure. But the people involved in the release don't have the manpower to do it. And JFTR it does not only involve taking care of the package list but also checking the dailies, checking for dependency problems, testing RCs etc.
Long story short, the persons involved in the release process don't have the manpower or interest in grml-xl. If you want to see changes please start contributing&testing what works and actually work on making grml-xl releases a reality.
Ulrich
P.S: For a more personal view on the release process have a look at the blog entry of ch http://zeha.at/blog/2011/12/grml-pissed-off.html
I have been running GRML as my main desktop for well over 5 years now, and I actually welcome their new changes.
The reason for that is that they have developed a great tool, grml-live, that installs and repackages new ISOs really easily. Make sure to get the updated version, though, as I poked quite a few holes in the one that got released with 2011.12.
I'm now currently running on a 800 MB image that has GRML_XL as well as additional packages that I personally want, which makes it even more flexible than it was before.
Granted, it's a little silly that you have to use this repackaging tool to get a 700 MB ISO, but that can be tricky if trying to get the exact size right with a certain amount of packages.
Because I use this environment all the time, I would be willing to step up and control GRML_XL, at least from time to time update it. I've already reported a few changes (remove ccrypt, hotkey-setup, sslscan, zoidberg), but GRML_XL will work with their new grml-live, and it should be ~700 MB.
I can't promise the quality, though, if I were to manage it. I don't really keep up to date with new Debian packages so if I were to do this I would need a bunch of people telling me what they want on it. I also have a ton on my plate, but releasing twice a year isn't so bad.
Just some thoughts.
-Brad
On Tue, Dec 27, 2011 at 07:43:06PM +0100, Ulrich Dangel wrote:
- Alexander Wirt wrote [27.12.11 16:45]:
For me grml was always an all purpose live cd for text users and zsh addicts. I always knew I could just load a grml a I would have a more or less complete working environment afterwards.
The problem is we don't have the manpower to do such a release. It was always cumbersome and stressfull for the persons involved in the release.
And the complete work environment was always a problem. Several times questions like these came up:
Q: Does package X make sense on a Live-CD? A: No but people may using Grml as a Dekstop system/work environment…
For me personally it was always unclear what the purpose of Grml was, what's its vision, what belongs on the CD, what does not. And i think with this release it became clear and obvious.
On the other hand I was able to just use grml-small if I needed a live cd just for booting and chrooting into the usual environment (i.e. for restoring the bootloader) or use -small as a base for my own customisations.
Releasing all different kind of flavours like grml-{full,medium,small}{64,32} resulted in six isos, which all had to be tested. And again there were typically not many people involved in testing the releases. It was neither fun nor interesting nor rewarding. It was just a lot of work for nothing really important. And this is not something new.
And what is the reason for using grml-small instead of the new grml-full? USB sticks typically have more then 350mb, if you want to use the ISO image on /boot in combination with grml-rescueboot you can mount a LVM LV over /boot/grml and use that.
That being said, i think that we maybe should/can reintroducde grml-small. Removing packages from a package list should result in less problems than adding new ones. But first we must get rid of grml-small specific hacks (IMHO).
Unfortunatly these assumptions aren't valid anymore. IMHO it is not a good idea to focus on rescue environments. GRML was known for two things: the great collection of well prepared text tools and their release names.
If you look around the internet about discussions for rescue systems, network stuff or other Live-CDs, Grml was never recommended as the first Distribution. Typically only one persons in the threads writing Oh but i like Grml. Thats it. And i personally think it is because Grml was everything and nothing. No area it was especially good at but tried to please everyone.
I don't think focussing on release names as the only unique feature is a good idea. There are rescue systems like ten a penny.
That's the reason I wrote http://blog.grml.org/archives/369-10-reasons-why-you-should-use-Grml-instead...
And it is not only rescue, it is also installation. Thats for example the reason we added rinse to the packagel ist.
Also wasting 350 mb of space on a cd is a (imho) stupid thing.
Wasting 4 GB on a DVD is also a stupid thing… I don't think the free space left on a device should be considered an argument at all. Only if it fits on a specific medium.
I want my old grml-small and -full back. And as it seems I am not alone.
grml-full is the flavour name for the current release. grml-xl is atm the old package list.
If someone steps up regarding grml-xl sure. But the people involved in the release don't have the manpower to do it. And JFTR it does not only involve taking care of the package list but also checking the dailies, checking for dependency problems, testing RCs etc.
Long story short, the persons involved in the release process don't have the manpower or interest in grml-xl. If you want to see changes please start contributing&testing what works and actually work on making grml-xl releases a reality.
Ulrich
P.S: For a more personal view on the release process have a look at the blog entry of ch http://zeha.at/blog/2011/12/grml-pissed-off.html _______________________________________________ Grml-devel mailing list Grml-devel@ml.grml.org http://ml.grml.org/mailman/listinfo/grml-devel
Ulrich Dangel wrote ...
The problem is we don't have the manpower to do such a release. It was always cumbersome and stressfull for the persons involved in the release.
Lack of manpower is a problem.
And the complete work environment was always a problem. Several times questions like these came up:
Q: Does package X make sense on a Live-CD? A: No but people may using Grml as a Dekstop system/work environment…
So why not dropping -medium, and also the 650 Mbyte limit for -full? I doubt many people still boot a Desktop system via CD, so I wouldn't bother about a -full image of 1 Gbyte. Perhaps other people would, I don't know.
For me personally it was always unclear what the purpose of Grml was, what's its vision, what belongs on the CD, what does not.
That's what you do user survey for. And you actually did.
So for me, there are two use cases:
1. Quite often: Use -small as a fits-everywhere system for rescue, recovery and repair on the root file system.. 2. Every now and then: Use -full to have a browser without touching the actual installation and/or without leaving traces behind.
But I always wondered who needs -medium and if asked, abandoning it would have been my first suggestion. But now, giving the impression you've dropped everything _but_ -medium is sending the message I'm not the target audience. Not a message I like.
And i think with this release it became clear and obvious.
For me, it's mostly: "We try to make one that fits all" (*)
Releasing all different kind of flavours like grml-{full,medium,small}{64,32} resulted in six isos, which all had to be tested. And again there were typically not many people involved in testing the releases. It was neither fun nor interesting nor rewarding. It was just a lot of work for nothing really important. And this is not something new.
Please don't tell you want to punish the satisfied Grml users just because they were happy with the way Grml was.
And what is the reason for using grml-small instead of the new grml-full? USB sticks typically have more then 350mb, if you want to use the ISO image on /boot in combination with grml-rescueboot you can mount a LVM LV over /boot/grml and use that.
Well, I want to use the ISO image on /boot (old-style, no-thrills /dev/sda1) all by itself, without having to rely on anything else on that disk. So I installed a -small image on each of my boxes and even on some external disks. Using USB sticks still may afford surprises - no BIOS support, BIOS support flaky and failing for that particular stick, BIOS providing just USB 1.x support, and mostly: Where the *beep* did I put the stick _this_ time?
Slurping the image into memory ("toram") is an important thing, too: If I want to fiddle with the partitioning, hence no partition my be mounted. Or just to make things fast.
But now:
* Not everywhere the disk has enough space in /boot for the 2011.12 image, and re-partitioning is a tiresome process even if using LVM (what I do), I don't want to do that again. * The copy operation of toram *is* fast on shiny new hardware. It's not so funny on older one. That time tripled now - no thanks.
Friends of mine - who were unanimously complaing about the loss of -small - also mentioned the situation of finding themselves alone in the wild with nothing but a broken machine where Grml would be a tool to fix it, and an internet connection. Why download 300+ Mbyte, and wait for it, if 110 did the job?
That being said, i think that we maybe should/can reintroducde grml-small. Removing packages from a package list should result in less problems than adding new ones. But first we must get rid of grml-small specific hacks (IMHO).
Bring back good ol' S^H-small. It's the main thing why I use, like and promote Grml. Doing a private -small release for myself might be a way to go but that's not helping, neither the Grml project nor other people who miss -small, too.
So, what were the -small hacks? Open tickets, or provide a pointer, and we'll see.
If you look around the internet about discussions for rescue systems, network stuff or other Live-CDs, Grml was never recommended as the first Distribution. Typically only one persons in the threads writing Oh but i like Grml. Thats it. And i personally think it is because Grml was everything and nothing. No area it was especially good at but tried to please everyone.
Rest assured Grml has a very pleased user base, perhaps a bit too quiet, and as always more taking than giving. A "Keep Grml just the way it is, it's almost perfect" might be boring but it's actually a compliment about the things you've achieved in the past seven-ish years.
My experience is a typical (Linux) sysadmin naturally just uses Grml without talking much about it. Especially when using Debian, Grml is the first choice as it's the same distribution.
So, please don't worry too much. Dare to ask for help if you need it. And bring back -small.
Christoph
(*) But see RFC 1926, (10)
* Christoph Biedl wrote [27.12.11 21:54]:
So why not dropping -medium, and also the 650 Mbyte limit for -full?
JFTR the limit was 700MB as we weren't able to put it into 700MB anyway.
grml-xl (the old one thing for all) is a lot more of work than the current grml-full. We needed to make a cut to do the release.
For me personally it was always unclear what the purpose of Grml was, what's its vision, what belongs on the CD, what does not.
That's what you do user survey for. And you actually did.
We made some mistakes in the user survey. Some questions (which i formulated) were unclear. Especially the CD/DVD limit ones. We were event told so by the users taking part in the survey.
So for me, there are two use cases:
- Quite often: Use -small as a fits-everywhere system for rescue, recovery and repair on the root file system..
I think we already had the discussion once but I can see the reason you don't want to place the ISO image on /usr or somewhere else.
- Every now and then: Use -full to have a browser without touching the actual installation and/or without leaving traces behind.
This still works with the current release.
But I always wondered who needs -medium and if asked, abandoning it would have been my first suggestion. But now, giving the impression you've dropped everything _but_ -medium is sending the message I'm not the target audience. Not a message I like.
No. We dropped all flavours and created one new one. Big difference. And at least i can see somehow the need for grml-small.
Many people doing the releases never felt really strongly about grml-xl and rarely used it. This is not a good thing to base your work on if you don't use it anyway.
And i think with this release it became clear and obvious.
For me, it's mostly: "We try to make one that fits all" (*)
Fits installation&recovery, but yes.
Releasing all different kind of flavours like grml-{full,medium,small}{64,32} resulted in six isos, which all had to be tested. And again there were typically not many people involved in testing the releases. It was neither fun nor interesting nor rewarding. It was just a lot of work for nothing really important. And this is not something new.
Please don't tell you want to punish the satisfied Grml users just because they were happy with the way Grml was.
We don't punish anyone. We don't offer treats or use carrots an sticks. The changes were not because we wanted to punish anyone but because the old process did not work. It was really stressfull and hard doing the releases. No one liked it, wanted to do it. So we had to change something managable and sustainable. Another option would have been stop doing any releases.
But now:
- Not everywhere the disk has enough space in /boot for the 2011.12 image, and re-partitioning is a tiresome process even if using LVM (what I do), I don't want to do that again.
I understand that. And don't change a running system etc.
- The copy operation of toram *is* fast on shiny new hardware. It's not so funny on older one. That time tripled now - no thanks.
You can do that always directly from the booted system with the grml2ram command. You can do this while working and don't have to wait until it is finished. (Disclaimer, i just noticed that due to some path changes the command no longer works atm)
That being said, i think that we maybe should/can reintroducde grml-small. Removing packages from a package list should result in less problems than adding new ones. But first we must get rid of grml-small specific hacks (IMHO).
Bring back good ol' S^H-small. It's the main thing why I use, like and promote Grml. Doing a private -small release for myself might be a way to go but that's not helping, neither the Grml project nor other people who miss -small, too.
So, what were the -small hacks? Open tickets, or provide a pointer, and we'll see.
I think for one the missing locales, exlcuding vmlinzu/initrd from the squashfs, the different behaviour wrt consoles (should be all the same), the specialized 98-clean-chroot script which removes imho too much stuff like aptitude. Main packages would be grml-live as well as grml-autoconfig.
If you look around the internet about discussions for rescue systems, network stuff or other Live-CDs, Grml was never recommended as the first Distribution. Typically only one persons in the threads writing Oh but i like Grml. Thats it. And i personally think it is because Grml was everything and nothing. No area it was especially good at but tried to please everyone.
Rest assured Grml has a very pleased user base, perhaps a bit too quiet, and as always more taking than giving. A "Keep Grml just the way it is, it's almost perfect" might be boring but it's actually a compliment about the things you've achieved in the past seven-ish years.
We would kept it the way it was _if_ the process would have been working. It were typically two to three people involved in the release process. It was not working for last release and even did not work for 2009.10. No one stepped up or offered something. So we had to change something to cope with the releases. Otherwise we would have dropped it.
So, please don't worry too much. Dare to ask for help if you need it. And bring back -small.
We may.
Ulrich
P.S: IMHO this clear cut was the best thing that happend ever to the project. Just because people started to discuss the project. P.P.S: Due to the cleaner and simpler release we are also already discussing a fixup release for the introduced bugs.
On Tue, Dec 27, 2011 at 07:43:06PM +0100, Ulrich Dangel wrote:
And what is the reason for using grml-small instead of the new grml-full? USB sticks typically have more then 350mb, if you want to use the ISO image on /boot in combination with grml-rescueboot you can mount a LVM LV over /boot/grml and use that.
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image. Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
That being said, i think that we maybe should/can reintroducde grml-small.
Pretty please.
Removing packages from a package list should result in less problems than adding new ones. But first we must get rid of grml-small specific hacks (IMHO).
The grml-small specific hacks were necessary to make grml-small fit on a business card CD. I haven't used that form factor in years and could live without.
Greetings Marc
* Marc Haber wrote [01.01.12 22:33]:
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image.
You can load the image into ram after you started it via the command grml2ram. This means you can copy it to ram while already working.
Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
As i said before you can place the grml iso images on a dedicated LVM lv or on raid and use that for mounting the isos. Stacked setups will work also (LVM on raid)
Ulrich
On Sun, Jan 01, 2012 at 11:10:40PM +0100, Ulrich Dangel wrote:
- Marc Haber wrote [01.01.12 22:33]:
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image.
You can load the image into ram after you started it via the command grml2ram. This means you can copy it to ram while already working.
Nice idea. How about an option to copy to ram in the background?
What do I do on old systems that only have 512 MB RAM?
Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
As i said before you can place the grml iso images on a dedicated LVM lv or on raid and use that for mounting the isos. Stacked setups will work also (LVM on raid)
That doesn't help too much for systems that are already installed.
Greetings Marc
* Marc Haber mh+grml-devel@zugschlus.de [120101 23:45]:
On Sun, Jan 01, 2012 at 11:10:40PM +0100, Ulrich Dangel wrote:
- Marc Haber wrote [01.01.12 22:33]:
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image.
You can load the image into ram after you started it via the command grml2ram. This means you can copy it to ram while already working.
Nice idea. How about an option to copy to ram in the background?
What do I do on old systems that only have 512 MB RAM?
Use an old release.
Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
As i said before you can place the grml iso images on a dedicated LVM lv or on raid and use that for mounting the isos. Stacked setups will work also (LVM on raid)
That doesn't help too much for systems that are already installed.
1GB is enough for kernels, initrds and Grml. Also, nothing forces you to put Grml into /boot. Choose something else if you can.
Generally speaking, having /boot seperate from / is one of those legacy errors that need to die.
-ch
On Mon, Jan 02, 2012 at 01:22:21AM +0100, Christian Hofstaedtler wrote:
- Marc Haber mh+grml-devel@zugschlus.de [120101 23:45]:
On Sun, Jan 01, 2012 at 11:10:40PM +0100, Ulrich Dangel wrote:
- Marc Haber wrote [01.01.12 22:33]:
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image.
You can load the image into ram after you started it via the command grml2ram. This means you can copy it to ram while already working.
Nice idea. How about an option to copy to ram in the background?
What do I do on old systems that only have 512 MB RAM?
Use an old release.
With old security-bugs? I don't like that idea at all.
Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
As i said before you can place the grml iso images on a dedicated LVM lv or on raid and use that for mounting the isos. Stacked setups will work also (LVM on raid)
That doesn't help too much for systems that are already installed.
1GB is enough for kernels, initrds and Grml.
Are you aware how big kernel debug infos are?
Also, nothing forces you to put Grml into /boot.
Up to grml 2011.05, grml forced me to do that. I haven't yet verified whether grml can find its iso on an LV on GPT. If so, that would be a big step forward.
Generally speaking, having /boot seperate from / is one of those legacy errors that need to die.
I still frequently have that for a number of reasons, that are unlikely to change.
Greetings Marc
* Marc Haber mh+grml-devel@zugschlus.de [120102 11:35]:
On Mon, Jan 02, 2012 at 01:22:21AM +0100, Christian Hofstaedtler wrote:
- Marc Haber mh+grml-devel@zugschlus.de [120101 23:45]:
On Sun, Jan 01, 2012 at 11:10:40PM +0100, Ulrich Dangel wrote:
- Marc Haber wrote [01.01.12 22:33]:
Loading an 350 MB image to RAM takes considerably more time than an 130 MB image.
You can load the image into ram after you started it via the command grml2ram. This means you can copy it to ram while already working.
Nice idea. How about an option to copy to ram in the background?
What do I do on old systems that only have 512 MB RAM?
Use an old release.
With old security-bugs? I don't like that idea at all.
I obviously don't understand your use case.
I thought this was about having an arch-specific Grml ISO in /boot for rescue purposes.
Where about the only things that matter are kernel and ssh. Both have been unpatched for the time since the last release anyway, which was up to 6+ months, depending on the release, and how often you update your ISOs.
Where there have been no such grave bugs in these software pieces in the past, that this was completely acceptable to everyone.
Additionally, on my typically 1 GB large boot, I was able to place to grml-small images in addition to the normal /bot contents. I was already forced to resize /boot on my notebook because of grmls size increase.
As i said before you can place the grml iso images on a dedicated LVM lv or on raid and use that for mounting the isos. Stacked setups will work also (LVM on raid)
That doesn't help too much for systems that are already installed.
1GB is enough for kernels, initrds and Grml.
Are you aware how big kernel debug infos are?
Installing linux-image-3.1.0-1-amd64-dbg did not change the size of /boot for me. I keep an old grml64 (full, so 700M) in /boot, and total size is <750M.
-ch
On Mon, Jan 02, 2012 at 01:38:00PM +0100, Christian Hofstaedtler wrote:
I thought this was about having an arch-specific Grml ISO in /boot for rescue purposes.
Indeed. That does not mean that the rescue system is allowed to have ancient security bugs, since it is likely to be exposed to the internet without filters if it is eventually started and needed.
Where about the only things that matter are kernel and ssh. Both have been unpatched for the time since the last release anyway, which was up to 6+ months, depending on the release, and how often you update your ISOs.
An ISO update could be done if a security relevant issue becomes public if a later ISO is available.
For grml-small, this is not the case any more, leaving a system using grml-small 2010.05 in 2014 open to all vulnerabilities that have become public in the mean time.
Installing linux-image-3.1.0-1-amd64-dbg did not change the size of /boot for me.
Interesting. When I install a kernel with debug info, vmlinuz size grows from like 2 MB to over a hundred.
Don't get me wrong: You took a valid decision which the community needs to accept. The community is not required to like your decision. I am one of the people not liking the decision, but I'm going to (have to) accept it anyway. That's ok, and given the lack of alternatives, I'm most probably going to stay with grml anyway. I am only going to do a lot of cursing in the next months whenever the new iso size bites me (which it will). But I'm going to get used to it.
Greetings Marc
On Tue, Dec 27, 2011 at 04:45:53PM +0100, Alexander Wirt wrote:
I want my old grml-small and -full back.
+1!
Greetings Marc
Teilnehmer (7)
-
Alexander Wirt -
Brad Cable -
Christian Hofstaedtler -
Christoph Biedl -
Marc Haber -
Marc Haber -
Ulrich Dangel