The pfSense Store

Author Topic: a pfSense roadmap  (Read 23491 times)

0 Members and 1 Guest are viewing this topic.

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21300
  • Karma: +1418/-26
    • View Profile
Re: a pfSense roadmap
« Reply #30 on: March 06, 2015, 09:59:21 am »
Blocks declared using whitespace!!! Gotta be the dumbest idea ever...

I'll take that over an unreadable perl script with no whitespace any day of the week. :-)

See above, re: coding style.

Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21300
  • Karma: +1418/-26
    • View Profile
Re: a pfSense roadmap
« Reply #31 on: March 06, 2015, 10:01:49 am »
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline Michael Sh.

  • Full Member
  • ***
  • Posts: 136
  • Karma: +0/-0
    • View Profile
Re: a pfSense roadmap
« Reply #32 on: March 06, 2015, 01:33:52 pm »
Also: http://www.secnetix.de/olli/Python/block_indentation.hawk

Mice were crying, injected, but continued to eat a cactus. ;D

50% of the source code holds significant whitespaces. Tabs canceled because for 20 years and have not decided what to do with them.
« Last Edit: March 06, 2015, 01:59:37 pm by Michael Sh. »

Offline Michael Sh.

  • Full Member
  • ***
  • Posts: 136
  • Karma: +0/-0
    • View Profile
Re: a pfSense roadmap
« Reply #33 on: March 06, 2015, 02:20:35 pm »
Blocks declared using whitespace!!! Gotta be the dumbest idea ever...

I'll take that over an unreadable perl script with no whitespace any day of the week. :-)

See above, re: coding style.

Well, yes, it is an advantage Perl. Read compressed JS is also impossible, but one press of the button in the editor and we can see the code in your favorite style to us. Just Perl and the vast majority of system programming languages so may, not only C-like, but Python - no. ;)

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21300
  • Karma: +1418/-26
    • View Profile
Re: a pfSense roadmap
« Reply #34 on: March 06, 2015, 02:28:19 pm »
Because you can't mangle python into an unreadable mess in quite the same way, so it's not necessary. :)
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline Michael Sh.

  • Full Member
  • ***
  • Posts: 136
  • Karma: +0/-0
    • View Profile
Re: a pfSense roadmap
« Reply #35 on: March 06, 2015, 02:34:08 pm »
That's what I watch a lot of programs available in Python byte-compiled code. Suddenly anyone in any wrong editor will open.  :D
« Last Edit: March 06, 2015, 03:04:44 pm by Michael Sh. »

gonzopancho

  • Guest
Re: a pfSense roadmap
« Reply #36 on: March 07, 2015, 10:24:07 pm »
Wot?

I design the API in the lift line.


Offline fatsailor

  • Jr. Member
  • **
  • Posts: 35
  • Karma: +2/-0
    • View Profile
Re: a pfSense roadmap
« Reply #37 on: March 11, 2015, 08:14:48 am »
You've clearly put a great deal of thought into the roadmap, and I'm impressed.The recently announced Intel Xeon SOC will be very interesting with v3.

One thought/suggestion regarding packages- have you thought about enforcing a rule that requires all third party packages to have a separate jail? Freenas does this now, and it improves the security and stability of the platform. It will make creating packages a bit more work, but with COW ZFS you won't waste disk.

(You are migrating to root on ZFS I hope).

gonzopancho

  • Guest
Re: a pfSense roadmap
« Reply #38 on: March 11, 2015, 07:22:29 pm »
You've clearly put a great deal of thought into the roadmap, and I'm impressed.The recently announced Intel Xeon SOC will be very interesting with v3.

One thought/suggestion regarding packages- have you thought about enforcing a rule that requires all third party packages to have a separate jail? Freenas does this now, and it improves the security and stability of the platform. It will make creating packages a bit more work, but with COW ZFS you won't waste disk.

(You are migrating to root on ZFS I hope).

Yes, we knew about Broadwell-DE (the codename for Xeon D), and kept it in-mind while evaluating our options.  We have a future product based on BDE in development.

root on ZFS: perhaps even for embedded.  The issue here is that ZFS eats ram for breakfast, and lower-end systems don't necessarily have same to spare.

We're quite aware of what the guys at iXsystems are doing with FreeNAS and PC-BSD.  First step here is to get to 'pkg(ng)' on pfSense.

Offline fatsailor

  • Jr. Member
  • **
  • Posts: 35
  • Karma: +2/-0
    • View Profile
Re: a pfSense roadmap
« Reply #39 on: March 11, 2015, 07:58:28 pm »

Yes, we knew about Broadwell-DE (the codename for Xeon D), and kept it in-mind while evaluating our options.  We have a future product based on BDE in development.

root on ZFS: perhaps even for embedded.  The issue here is that ZFS eats ram for breakfast, and lower-end systems don't necessarily have same to spare.

We're quite aware of what the guys at iXsystems are doing with FreeNAS and PC-BSD.  First step here is to get to 'pkg(ng)' on pfSense.

ZFS only really eats RAM when deduplication is used. The COW capability of ZFS combined with Jails is light years ahead of Docker et. al.

I agree that getting pkg working is the first step, and I love that you're getting rid of PHP!

Offline riahc3

  • Full Member
  • ***
  • Posts: 135
  • Karma: +3/-4
    • View Profile
Re: a pfSense roadmap
« Reply #40 on: March 20, 2015, 02:37:02 pm »
I am against the idea of dropping PPTP.

While I agree deprecating it and not supporting it (hell, hide it if necessary), there are a lot of industrial machines that only support PPTP. For example, PLCs come to mind.

I understand the reason and I agree that noone should use PPTP but thats not a reason to remove it. With it disabled and/or not recommended, it does not hurt pfSense. Whoever chooses to enable it, is under his/her own consequences.

Offline doktornotor

  • Hero Member
  • *****
  • Posts: 8553
  • Karma: +956/-278
  • Not a pfSense employee, they cannot fire me...
    • View Profile
Re: a pfSense roadmap
« Reply #41 on: March 20, 2015, 03:08:04 pm »
With it disabled and/or not recommended, it does not hurt pfSense.

I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Do NOT PM for help!

Offline kejianshi

  • Hero Member
  • *****
  • Posts: 4902
  • Karma: +194/-40
  • Debugging...
    • View Profile
Re: a pfSense roadmap
« Reply #42 on: March 20, 2015, 05:30:23 pm »
"While I agree deprecating it and not supporting it (hell, hide it if necessary), there are a lot of industrial machines that only support PPTP. For example, PLCs come to mind."

I assume these PLCs are sitting behind a router?  Why not let pfsense tunnel all the stuff you used to use PPTP for over a different type of vpn?

I can't imagine a situation (other than being unable to purchase or build a pfsense) where you can't replace PPTP.

Offline riahc3

  • Full Member
  • ***
  • Posts: 135
  • Karma: +3/-4
    • View Profile
Re: a pfSense roadmap
« Reply #43 on: March 21, 2015, 12:29:22 pm »
With it disabled and/or not recommended, it does not hurt pfSense.

I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.

On top of that, don't write whatever the fuck you want; 2.3 is set to drop PPTP. 3.0 is far away from us. The rewrite isnt even taking in though PPTP.

2.3 should be released with PPTP "as-is" and disabling/hiding it unless the user himself decides to enable it. If it drops in 3.0 (whenever that is in the far future), so be it (depending on what timeframe, I would probably be for dropping it).


Offline riahc3

  • Full Member
  • ***
  • Posts: 135
  • Karma: +3/-4
    • View Profile
Re: a pfSense roadmap
« Reply #44 on: March 21, 2015, 12:31:37 pm »
I assume these PLCs are sitting behind a router?  Why not let pfsense tunnel all the stuff you used to use PPTP for over a different type of vpn?
Because old stuff is usually only compatible with PPTP.

I just gave my point of view; I understand that security wise (and technology wise) the choice to drop PPTP, I just dont agree removing it; I think it should be unsupported.