Re: libXO-ification - Why - and is it a symptom of deeper issues?
Hi Dan, Sounds like you'd be interested in NextBSD: https://en.wikipedia.org/wiki/NextBSD Cheers, Yonas On 11/15/2015 07:54, Dan Partelly wrote: Hi all, I was looking at the new facility of dumping JSON,XML from many utils in base and after some funny minutes, I couldn't stop ask myself “ Ok, this is funny , but why ? “ And I couldn't find a real answer. Ill outline what I think: 1. Undoubtedly, it makes base code slightly harder to understand and maintain. 2. I have seen the idea that this makes the information dumped by utilities in the base easily accessible programatically. OK, maybe it does , but it doesn't fit with the current paradigm of "tool | filter | tool” at all. There are no tools able to accept JSON and filter it in any meaningful way, and I dont see too many ppl changing their code to read JSON instead of text. I don't even see the base tools changing. This output may be useful in corner cases only. 3. The integration of libxo IMO only points at a much deeper issue IMO. It is only an expression of the need of a mechanism aimed at binary code reuse. But it does not solve the problem, it only adds yet another possibility in a world where too much choices already result in too much splits and incompatible APIs. 4. This whole effort would have been IMO much better served by porting the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, much like the libs for geom, zfs , etc , ready for reuse of 3rd party code. Eventually writing network control daemons in time over it , much like solaris does. 5. A port of partial OS config data to UCL …. would induce yet induce another orthogonality violation. What makes UCL better than the bestiary of ad hoc databases already existing in BSDs ? Programatic readability, yes. but it does not add any real much needed functionality such as *transactional databases* for system tools. Why not research a proper solution - easily accessible by other programs ,orthogonal , transactional, and ACL protected solution which can be used all over the place , from OS boot, to ABI management, service management, network management, user management. I hope this day will come, a day when I will not have to edit a single config file manually, yet I would have access to all the config and system state easy with wrapper APIs. In the light of this point, why go with UCL ? It is not orthogonal, it is not transnational, and editing the config files directly would result in the same old human errors which bite as all from time to time. 5. It is my opinion that Solaris addressed some of those issue. Solaris FMRI and SMF are lightyears ahead of the very tired models we keep using on BSDs. Why not build on the insight offered by those (or even on the insight offered by Windows :P) , then inventing more adhoc solutions and ad-hoc databases, which do not address the real issues we have , like binary code reuse, service management issues, lack of a system wide published -subscriber bus ( not kdbus :P ) fault detection and reaction, fault reporting, all much needed parts of a modern OS. And now thee questions 1. Why lib XO ? Why burden the OS for some corner cases where it may be useful ? 2. Was there any real talk on how to bring FreeBSD up to speed regarding those issues ? A period of research on what exists, on what can be done , and ensure important things are not showed in background and replaced with yet another ad-hoc config database which lacks modern features ? From where I am standing, this could be a project spawning multiple years , but it would be well worth it, and in my opinion it would be also worthy of the freeSBD foundation sponsorship for several years in a row. The features I touched upon became very important parts of oder OSes, and rightly so. Note: this message is serious and it is not intended to start flame wars, religious crusades, or offend anyone. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Yonas Yanfa In Love With Open Source Drupal <http://drupal.org/user/473174> :: GitHub <http://github.com/yonas> :: Mozilla <https://addons.mozilla.org/en-US/thunderbird/user/4614995/> :: iPhone <https://github.com/yonas/ffmpeg-iphone-build> fizk.net | yo...@fizk.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Tunnelling IPv4 over IPv6 for GitHub access?
On 11/02/2015 17:04, Craig Rodrigues wrote: Hi, I have some machines which are on an IPv6 only network. It works great and I can access most things on the IPv6 Internet that I need like Google ( [2607:f8b0:4004:808::1014]) , Facebook ([2a03:2880:1010:df05:face:b00c:0:2]), CNN ( [2620:100:e000::8001]), etc. However, the one thing I cannot access is GitHub, which does not support IPv6 (). Is there a way that I can tunnel IPv4 over an IPv6 network? I read this blog post: http://www.aisecure.net/2013/02/03/tunneling-ipv4-over-ipv6-vpn/ and wasn't sure if this was an approach that I could use. -- Craig ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Weird how such a geek central place like GitHub doesn't support IPv6 o_O. I'm unfamiliarity with tunnelling IPv4 over IPv6, but I'm curious if the guide you found on aisecure.net worked for you? I would give it a shot if you haven't tried them yet. It was written only a few years ago (2013), so it could still work. Cheers, Yonas -- Yonas Yanfa In Love With Open Source Drupal <http://drupal.org/user/473174> :: GitHub <http://github.com/yonas> :: Mozilla <https://addons.mozilla.org/en-US/thunderbird/user/4614995/> :: iPhone <https://github.com/yonas/ffmpeg-iphone-build> fizk.net | yo...@fizk.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Depreciate and remove gbde
On 10/20/2015 01:27, Poul-Henning Kamp wrote: In message , NGie Cooper writes: 1. Why are there 2 competing technologies? They are not competing, they support two very different threat models. We need to make this a lot more clear in the Handbook. John-Mark is taking the charge here. 3. Is there a gain/loss for removing gbde? Yes, you alienate a lot of users who very often are not even in a position to tell you they run FreeBSD. Think human rights activists for instance. Couldn't they use a fake email address and Tor to communicate anonymously? I'd be surprised if they aren't already. As I said to Martin, this point keeps coming up as though its grounds alone to leave gdbe in the tree forever. gdbe should stand on its technical merits. After reading your paper on gdbe, I understand those merits a lot better, but we should improve the Handbook so gdbe vs. geli strengths and weaknesses are better explained. 4. Why is it marked experimental [still]? To make people think. What it made me think was - "this software has been here for so many years and is still experimental and suspect??? It must have issues. Why is it still in the tree?" Yonas -- Yonas Yanfa In Love With Open Source Drupal <http://drupal.org/user/473174> :: GitHub <http://github.com/yonas> :: Mozilla <https://addons.mozilla.org/en-US/thunderbird/user/4614995/> :: iPhone <https://github.com/yonas/ffmpeg-iphone-build> fizk.net | yo...@fizk.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Depreciate and remove gbde
Hi Martin, thanks, that raises some interesting points. After reading PHK's paper on GBDE, I can see enough differences between GDBE and GELI that warrant keeping GDBE. [ At this point for me, this part is theoretical, but it's still interesting ] I've seen the concerned made a few times that we need to support existing users. That's true up to a point. There's always going to be a way to transition from GDBE to GELI if we really want to (eg. a conversion tool), or were forced to for any reason (full decrypt and re-encrypt), so we shouldn't be keeping GDBE in the tree solely for this reason alone. GDBE should be in the tree for it's technical merits (which I've found it does have). However, if it turns out in X years from today GELI can do everything GDBE can do and better, then I would say we should figure out a way to remove GDBE. On Mon, Oct 19, 2015 at 7:44 PM, Martin Cracauer wrote: > Yonas Yanfa wrote on Sun, Oct 18, 2015 at 06:36:19AM -0400: > > > > Is there any objection to removing gbde? How many people use gbde? When > > have you used gbde over geli, and why? > > You would exclude all current users from accessing their existing > filesystems or whatever they put into that block device. > > A conversion tool would pretty much be forced to use the current > kernel layers (doing the block chaining in userspace would be > annoying), and it would be fundamentally unsafe to have your > half-converted filesystem on disk in case of an interruption. Plus I > think GELI uses a bigger header so you might fall short by a couple of > bytes and you can't do anything about it on the block level with no > access to the filesystem. > > And people might not have their gbde units accessible right now, it > might be on a laptop in a closet on a different continent. > > Martin > -- > %%% > Martin Cracauerhttp://www.cons.org/cracauer/ > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Depreciate and remove gbde
Hi, It seems geli is the standard way of encrypting disks. It's extremely flexible and usually recommended by the community over gbde. Moreover, geli is mentioned a lot more in the mailing lists and forums. gbde's man page explicitly says that gbde is experimental and should be considered suspect. That seems reason enough to finally depreciate and remove it in favour of geli. The Encrypting Disk Partitions page in the Handbook discusses gbde first, and describes geli as an alternative. This seems odd, shouldn't this be the other way around? Is there any objection to removing gbde? How many people use gbde? When have you used gbde over geli, and why? Cheers, Yonas -- Yonas Yanfa In Love With Open Source Drupal <http://drupal.org/user/473174> :: GitHub <http://github.com/yonas> :: Mozilla <https://addons.mozilla.org/en-US/thunderbird/user/4614995/> :: iPhone <https://github.com/yonas/ffmpeg-iphone-build> fizk.net | yo...@fizk.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Add isboot iSCSI boot driver to FreeBSD
Hi, isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you to boot your root partition using iSCSI. Installation is extremely simple: 1. extract the archive: # tar zxvf isboot-x.x.x.tar.gz 2. compile the module: # cd isboot-x.x.x/src # make 3. install the compiled module to the kernel directory: # make install 4. edit /boot/loader.conf, and add the following line: isboot_load="YES" This was first announced way back in June, 2010: https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 booting a ZFS on root installation: http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz I've used iSCSI boot with Ubuntu Server for a while and it's been very useful. I'm looking forward to FreeBSD having the same capability built-in. Cheers, Yonas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
