Re: GSOC 2013 project " Kernel Size Reduction for Embedded System "
On Tuesday, 9 April 2013 at 22:18, Joshua Isom wrote: > Would clang's LTO help for size? I know work's starting on the bsd > elftools ld, but I doubt it has any LTO support yet. Running -Os on the > kernel as a whole instead of object files could probably help a lot > also. I might try to set it up and see a size comparision. The last I heard, LTO on the kernel required something like 16 GB of RAM and produced a not-quite-working image. Jon -- Jonathan Anderson Research Associate Computer Laboratory University of Cambridge jonathan.ander...@cl.cam.ac.uk +44 1223 763 747 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: lib for working with graphs
On Wednesday, 28 November 2012 at 14:37, Andriy Gapon wrote: > Graphs as in vertices, edges, etc :) > And things like graph basics: BFS, DFS, connected components, topological > sort, etc > I've used igraph in my research: http://igraph.sourceforge.net/. It's very full-featured, with attention to efficiency and sensible choices for (at least some) algorithms, but it is GPL'ed rather than BSD-licenced. > And, big oops sorry, forgot one very important detail - it has to be C. Does it have to *be* C, or does it have to be *interoperable with* C? For instance, igraph has a core C library to do the heavy lifting, but I'd never want to use it directly when exploring data sets because the Python wrapper API is so very convenient (and I can pop the resulting data into matplotlib). Jon -- Jonathan Anderson jonat...@freebsd.org (mailto:jonat...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On 5 Jul 2012, at 18:21, Mike Meyer wrote:
>> The command line shouldn't have to be a scary place for new users.
>
> Nor should it be an annoying place for old users. New users are
> important. But old users are the ones who make contributions.
No argument there. :)
I do like the idea (Garrett's, maybe?) of providing such a tool, leaving it off
by default, making it very easy to turn on ("if you run this command, the shell
will be friendlier to you") and letting the PC-BSD folks turn it on by default
for their users.
Jon
--
Jonathan Anderson
jonat...@freebsd.org
http://freebsd.org/~jonathan/___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On 5 Jul 2012, at 15:36, Wojciech Puchar wrote:
>> mwm@IPGhosterCrawlerI:~$ mmap
>> No command 'mmap' found, did you mean:
>> Command 'jmap' from package 'openjdk-6-jdk' (main)
>> Command 'jmap' from package 'openjdk-7-jdk' (universe)
>> Command 'gmap' from package 'gmap' (multiverse)
>> Command 'gmap' from package 'scotch' (universe)
>> Command 'tmap' from package 'emboss' (universe)
>> Command 'smap' from package 'slurm-llnl' (universe)
>> Command 'pmap' from package 'procps' (main)
>> Command 'moap' from package 'moap' (universe)
>> Command 'umap' from package 'libunicode-map8-perl' (main)
>> Command 'map' from package 'sgt-puzzles' (universe)
>> Command 'amap' from package 'amap-align' (universe)
>> mmap: command not found
>
> are you serious that linux distros have such a think now?
> I didn't use linux for a long time and no plan to use it, but you are joking
> isn't it?
They do, and it's actually very useful in two cases:
1. new users — "my friend told me to try out latex, but when I type 'latex'
nothing happens! oh wait, that's how I make it work"
2. confusingly-named packages. on FreeBSD:
[nick ~]$ latex
zsh: command not found: latex
[nick ~]$ pkg search latex | awk '{print $1}'
latex-chapterfolder-2.0.20051124
latex-supertabular-1_3
ja-latex2html-2002.2.1j2.0_11
latex-beamer-3.07_4
latex-feynmf-1.08.19961202_7
pidgin-latex-1.0_5
latex-biblatex-0.9e
latex-pgf-2.10
latex-svninfo-0.7.4_3
latex-keystroke-1.0.20001109_5
latex-aastex-5.2_3
klatexformula-3.1.2_2
latex-nomencl-4.2.20050922
jlatexmath-0.9.7
latex-acm-1.1
latex-circ-1.0f_5
html2latex-0.9c
rtf2latex2e-1.0
latex-timing-1.0.19940515_6
latex-aa-6.1_3
latex-ucs-20041017_5
tomboy-plugin-latex-0.6
latex2e-2003.12_1
latex-etoolbox-2.0.a
db2latex-0.8p1_1
dblatex-0.3.2
latex2html-2008
latex2slides-1.0_5
platex-jsclasses-1.0.20110510
ja-platex-otf-1.2.4_6
ja-platex209-1.0_7
latex-mk-2.1_2
rtf2latex-1.5
latex-prettyref-3.0_4
latex-texpower-0.2_4
latex-arydshln-1.71.20040831_5
latex-logreq-1.0
cpp2latex-2.3
latex-biblist-1.4.19920113_5
platex-japanese-1.3_4
latex-caption-3.1.20100114_1
latex-auto-greek-1.0b_4
latexmk-431
latex-service-0.1_2
latex2rtf-2.0.0
latex-tipa-1.3_4
latex-mathabx-1.0.20050518_4
latex-logpap-0.6.20040201_5
htmltolatex-1_15
latex-bytefield-1.2.20050731_5
latex-resume-20010823_3
latexdiff-0.5_2
easylatex-0.080
csv2latex-0.18,1
latex-subfloat-2.14.20030821_5
latex-csquotes-5.0b
latex-ltablex-1.0_1
latex-cjk-4.8.2_5
Compare to bash on Ubuntu:
[jra40@kent ~]$ latex
The program 'latex' is currently not installed. You can install it by typing:
sudo apt-get install texlive-latex-base
This kind of thing makes the system *very* discoverable for non-experts (even
non-experts wrt a particular package). You don't need to check mailing lists or
freshports or whatnot, you can just try stuff out, and when it doesn't work,
the system sometimes helps you find the thing you're looking for. For some
people (like me), "just try stuff out" is an excellent way to start playing /
getting familiar with a new system; it makes it more likely that I will stick
with that system.
The command line shouldn't have to be a scary place for new users.
Jon
--
Jonathan Anderson
jonat...@freebsd.org
http://freebsd.org/~jonathan/___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Capsicum project: Ideas needed
On 8 July 2011 12:09, Ilya Bakulin wrote:
> modification of inetd itself is NOT sufficient and
> ineffective, capability support implies modifying code of daemons
Speaking as someone who isn't terribly familiar with inetd:
One could imagine inetd (or an inetd-like service) accepting
connections, wrapping them up with capability rights masks, and
forking capability-mode daemons that can't e.g. reconnect a socket.
See comments about unmodified binaries, below.
>> -any interpreter (perl, python, etc)?
> Proper capsicumization of these things requires heavy code hacking, and
> probably won't be accepted by upstream anyway, until Capsicum becomes a
> standard not only for BSD world. Should hold on for now.
Fair enough. I think the language-level things are probably a better
target for CTSRD, whose vocabulary includes fine-grained memory
regions, rather than (relatively coarse) files and processes.
>> -any shell?...
> Processes that are started by the shell will inherit its capabilities. So
> this is undesirable IMHO. We should modify applications themselves.
Do take a look at https://github.com/trombonehero/capsh, which is a
(not-fully-functional-as-a-shell-yet) capability-aware shell. It
executes child processes in capability-mode sandboxes, providing
access to explicitly named resources via library preloading (replacing
the regular open() and friends, which will die with ECAPMODE, with
versions that search through a list of explicitly inherited files).
The philosophy is a bit like Plash, but the details are built on
Capsicum foundations.
As I said, I wouldn't call it functional yet, but it does allow me to
run simple binaries, e.g. cat, unmodified but in a sandbox. So while I
agree that it's good to modify applications to take advantage of
Capsicum, there is some exploration to be done in bringing
Capsicum-backed security improvements to unmodified applications.
>> minicom
>> wget
>> curl
>> links/lynx
> This is Ports software, we may try to modify it and even send patches to
> upstream, or maintain our local patches. I wanted to focus on base system
> components during GSoC, but it doesn't hurt to try to capsicumize these
> tools either.
>
> From your first email:
>> How about sendmail and bind?
> I don't know how many people actually use sendmail in base system?
> Regarding bind -- it's a good idea, though bind already includes support
> for running in jail AFAIK.
Both of these do seem like ideal candidates. Jail support is actually
a plus: it means that some of the compartmentalization work might
already be done for you, and provides a comparison point (evaluation
with Jail, Capsicum and Jail+Capsicum).
>> Can it be made a switch on sudo?
>> sudo --sandbox=someprofile,option tcpdump -tti pflog0
Interesting... this starts to sound a bit like Mac OS X's sandbox
policy files ("run this binary, constrained by policy X.sb"). I think
that the capsh/Plash approach is a more natural fit for capabilities
(policy files fit nicely with MAC), and indeed, a more natural tool
for the job we're trying to do here.
Perhaps 'sudo --sandbox command infile:r outfile:rw' could do
something very much like what capsh tries to do.
Jon
--
Jonathan Anderson
Research Student, Security Group
Computer Laboratory
University of Cambridge
+44 (1223) 763747
jonathan.ander...@cl.cam.ac.uk
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
