Re: Would DF welcome a phpbb forum?
if, like me, you don't like mailing lists flooding your mailbox, you'll be glad to learn that those same mailing list are bridged to a nntp server: nntp.dragonflybsd.org just subscribe, no need for tedious login, signup, etc... much more convenient than a those forum web app IMHO, despite it being "15 years old tech". cheers Raphael [EMAIL PROTECTED] wrote: Indeed, it would be like users@, but consider: 1) In what way can you order threads in a mailing list? If we had a web-based forum we could easilly have stuff related to hardware in one forum, multimedia in another, pkgsrc in another etc., we could even have a forum for non df-related stuff. Sure, you can make more mailing lists, but: 2) Assume that DF is going to gain much bigger popularity, im not talking about hundreds of users like now, im talking about thousands. Can you imagine users@ with 10x (or even more) people posting one over another all different stuff? Thats confusion! You arent going to attract people to DF with a mailing list like that. 3) When users want to ask questions to another users, whats easier than sign up, log in and make a new thread and discuss whatever you wish. Sorry, but a mailing list might have been a hype of 15 years ago when people had a 14.4kbps dialup connection to the internet or even less, but today? Sure its easy to open up evolution or mutt and send mails to users@, but is this attractive to new users coming over over from Linux and *BSD? The guy that wrote the review of DF 1.4 on Distrowatch was correct when he said that DF is for hardcore geeks, because only geeks like us would bother mailing questions to users@ today in 2006 when pretty much every project that is trying to make it somewhere far has a proper forum that suits the age (and for a reason!) Dont take this as bashing please, i really _like_ what you guys are doing in the software section. Im just trying to help out. petr
Re: DP performance
Danial Thom wrote: What do you think "my word" is? My only point was that I use the usage level at which a machine starts dropping packets to determine its point of capacity. I don't see how I can be wrong about anything, since its hard to argue against that point. And what do you think Matt's point was? I don't even think its relevant. .. Whoever you are, you are maybe knowledgeable. I am personaly not able to judge. But your problem is psychological, not technical. I don't know what you are looking for by harrassing people on technical forums such as this one. But whatever you are looking, nobody can ever give it to you. At this point, there is enough element here and then for you to realise the problem lies within you. Get the appropriate help (maybe even a psychatrist for a starter, tough to find a good one though). best of luck Raphaël
Re: DP performance
Danial Thom wrote: you also obviously have no practical experience with heavily utilized network devices, because you seem to have no grasp on the real issues. you sound like a teenager telling his mum she has no experience in life and she can't "get it"... Matt, I really appreciate your way of never getting tired of explaining the technical subtilities regardless of who is asking, and what motivates him. It looks like you have that obsession of turning even the sillyest question into an insightful answer. You should consider teaching, if that's not the case already. best regards Raphaël
Re: [OT] Micro$oft versus security
For those, like me, who are not at ease with mathematics but still want to have a practical understanding of the problem, I can only recommand O'Reilly's "Secure programming Cookbook for C and C++". Although I don't cod in C, it gave me a good insight into applied crypto and security in general. cheers Raphaël Rob D. wrote: walt wrote: I just got this item from SANS, and I still can't quite believe what my eyes are seeing: == --Microsoft Bans Weak Crypto in New Code (15 September 2005) A new policy at Microsoft bans developers from using functions using the DES, MD4, MD5 and in some cases the SHA1 encryption algorithms in their code because increasingly sophisticated cyber attacks are threatening the security of these algorithms. Microsoft recommends the use of the (Secure Hash Algorithm) SHA256 encryption algorithm and (Advanced Encryption Standard) AES cipher. The decision comes as part of Microsoft's twice-a-year update to its Secure Development Lifecycle policies. The company also hopes eventually to remove the vulnerable encryption from older code. http://www.eweek.com/print_article2/0,1217,a=160307,00.asp [Editor's Note (Schultz): Microsoft deserves a proverbial round of applause for its decision concerning use of cryptography in its products. (Schneier): This will improve potential security for their products at the cost of backwards compatibility -- I call that a good trade-off.] === I have Schneier's second edition of Applied Cryptography (which is where I learned what little I know about the subject) and he does a good imitation of someone who really knows the subject. I can cite decades of bad (or ridiculous) decisions by M$ concerning anything to do with security -- but seeing Schneier's name attached to this article makes me wonder if things have changed... Anyone here agree that MD5 and SHA1 are 'weak' crypto? Any other thoughts about the subject? http://www.cits.rub.de/MD5Collisions/ To many crypto/authentication algorithms, if two files (or messages) have the same hash and same size, then they're identical. I think the general consensus in the crypto community is that MD5 and SHA-1 shouldn't be used in any new designs, especially considering that stronger (and longer) hash algorithms already exist. If the researchers keep cracking away at MD5, schemes that already use it might have to be outright replaced, if that's not already the case. I wish I was more of an expert on this, and apologies to the crypto community if I've misrepresented their views.
Re: Accessing 'hidden' sectors on hard drives
And what happens when two programs use "sector 32" for storing their copy protection key? ;) cheers Raphael Jonathon McKitrick wrote: I was reading recently about a copy protection scheme that stores data in sector 32, which is apparently right after the partition info, correct? The scheme I am looking at claims to defeat Norton Ghost and yet survive a format... probably not low-level. However, they will not reveal the details of where the license info is, except to say it is not 'in the filesystem.' Do these unused, reserved, or 'system' sectors exist on a UFS/FFS hard disk? If I am 'dangerously dedicated,' does that extra space go away? Is there any way a copy protection scheme could be devised under FreeBSD that could access that area, or another area beyond the reach of the filesystem? Jonathon McKitrick -- Hoppiness is a good beer.
Re: Compatability with FreeBSD Ports
Your post further clarifies things. I am also of the opinion that what is lacking are tools above the purely build/packaging layer, as long as the latter provide the necessary services. Jeremy C. Reed wrote: As for an apt-get (or yum or up2date) replacement, we need a "available" database that lists detailed metadata about each available package. Then we need a tool to use this database to make smart decisions on ordering (deinstalls if needed) and installation. This is unrelated to pkgsrc. pkgsrc makes the packages. You provide the tool. I have provided example scripts, example databases and ideas for the "available" list. Could you give me an url where you put these exemples and scripts? Also, is it possible to have pkgsrc keep several installed package databases? thanks in advance Raphaël
Re: Compatability with FreeBSD Ports [debian package tools]
Joerg Sonnenberger wrote:
On Thu, Aug 18, 2005 at 06:29:43PM +0200, Gabriel Ambuehl wrote:
If anything, it should be thought further (and some are already pressing
in that direction, notably Xen and VMware ESX): self contained
single purpose OS instances.
A nice hype, but IMO a nightmare for administration.
One machine might easily do both web and mailserving, but it would be
more secure to isolate the services...
It's called separate user accounts in Unix.
A package manager that can do something like that would be truly innovative.
No, because it wouldn't be package mangement at all. You end up with
extracting a tarball into a location and removing it for uninstall,
pretty much like Windows, just without messing in
C:\Windows\System{,32}.
Certainly not. A sandboxed app would be built by installing packages
_into_ it. As as said, this is why it must be managed by a high level
program, that not only gives the operator a clear picture, but allows
him to upgrade whole "sandboxes", upgrade a single packages, a single
package in all "sandboxes", etc...
As per config files, sure, this can be a pain. But nothing prevents to
be smart and inovative, and have the package manager provide a list of
the config file of all installed instance of a given package, along with
the modification date, and why not, diff between them, revision conrol,
.. once the system is solid and predictable, you can put the wizardry
in managing usefull info: the configs.
Frankly, are there so many dependency packages that need configuring
beyond the defaults? Most of the time, I bet you need do so to taylor
them to their dependent package. At this point, its really the same. I
doubt there would be so much real config duplication.
All in all, you spend a little more energy and disk space at the install
phase and maintenance phase, so you spend no energy in keeping the
system from derailing, and no energy and disk space at the removal of
components.
In the current scheme, you spend as little energy and disk space as
possible installing. Then spend vast amounts of energy at keeping the
system from gaining entropy, then spend a fair amount of energy and a
some disk space at the removal of components.
In the end, we are no so far from the windows world ;)
Raphael
Re: Compatability with FreeBSD Ports [debian package tools]
Joerg Sonnenberger wrote: On Thu, Aug 18, 2005 at 01:39:05AM +0200, Raphael Marmier wrote: While strictly copying MacOSX is not an option, our dream package management system should allow us to install an application and all its dependencies in its own directory, possibly with its own config space. This would be called "standalone" application, maybe. This is what you can do already with pkgsrc or (perhaps to a slightly lesser degree) with ports. Just build the "standalone" application and its dependencies with a LOCALBASE of /opt/myapp and make a tarball of the whole thing. great, I'll give it a try! The reason why this is not used by default for normal system distribution is the high amount of redundancy and that not every dependency just works out of the box. As soon as a library needs a config file itself, you have to break the sandbox and you loose most advantages in that case. I'm not sure I understand. The config would go in the sandbox as well in a ./etc directory. Of course, it has the potential of duplicating configs as well. But if you had to learn how to configure package x, you can configure it again without to much effort. And you don't have to struggle to make it work at the same time for package y and for package z. In summary, this concept works best for distributing "shrinkware" like Office programs, but is not such a good concept as general package system. You have a point. However, little research has gone into this kind of system so its inherent difficulties haven't been tackled. Also, most software is written in the mindset of the "big holistic /usr/local", maybe adding further complication. I've just come to think that such a system would fit nicely into the DragonflyBSD attitude to "simplify to scale". I don't beleive that much in vfs voodoo anymore. best regards to all Raphaël
Re: Compatability with FreeBSD Ports [debian package tools]
Gabriel Ambuehl wrote: Long story short: the perfect system doesn't yet exist. OSX .app approach comes close but is totally different paradigm and not really what a BSD should be after. While strictly copying MacOSX is not an option, our dream package management system should allow us to install an application and all its dependencies in its own directory, possibly with its own config space. This would be called "standalone" application, maybe. something like: /usr/standalone/apache-2/bin ./etc ./lib ... possibly, an option would have it installed in such a way that it is ready to be chrooted (maintaining a copy of the necessary system libraries) This way, it is possible to separate important applications from the other stuff. Then you gain peace of mind. You can use apps such as portupgrade -a on the non important stuff and manage each critical app separatedly, which makes them much less dangerous to upgrade by the way. Disk space is cheap so I don't mind the duplication of libraries caused by such a scheme. And when you want to clean the mess, you just drag the app to the Trash .. er ... cp -R . are views something like this? please be kind, I am far from understanding the subject Raphael
Re: Possible Filesystem Corruption
I will wait for these big upcoming changes and set back up with crash dump support when I figure out how. The wiki has a howto on the steps needed to get a core dump: http://wiki.dragonflybsd.org/index.php/HOWTO/Create_a_coredump regards Raphael
