Re: Tools for writers
hello, > https://www.openbsd.org/papers/bsdcan18-mandoc.pdf which leds me to the conference video. it was really interesting. > Nothing is wrong with trying to make things simple for users, quite > to the contrary. But that is not an excuse for delivering solutions > that are technically abominable. ok. now i get your honorable point but the lazy part of me will take its part of abomination to get things done in a pleasant way :) also: i didn't dive that much in pandoc code but from what i saw: even a non-fluent haskell person which i am can read this code. > When a language is technically > as ill-designed as markdown is, the multitude of resulting traps > actually makes it very hard to use, *not* easy at all. well ... i really think this is a bias because i really think markdown is so easy to use it popularized the use of wiki syntaxes (which mean less use of wysiwyg tools ... which is more abominable). let me ruin your day: are you aware of scdoc? https://git.sr.ht/~sircmpwn/scdoc i really appreciated reading about you opinion. thank you. regards marc
Re: Tools for writers
Hi Steve, Steve Litt wrote on Tue, Nov 05, 2019 at 06:38:52PM -0500: > On Tue, 5 Nov 2019 18:38:03 +0100 > Ingo Schwarze wrote: >> Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: >> [ Pandoc ] >>> is one of the most useful tools I have ever used. If you are >>> writing any sort of documentation then I *highly* recommend >>> checking it out >> I strongly oppose that point. Admittedly, this was a bit of a diversion because the OP asked about long, general-purpose texts like books - but all the same, it didn't want to let the statement "pandoc is recommended for *documentation*" go unchallenged. [ mdoc(7) ] > no method of creating a header hierarchy like ... > I'd suspect it could be done by nesting .Sh lines, No, .Sh does not nest at all. > no way to declare arbitrary styles. > can't make new kinds of lists That's all perfectly true. The mdoc(7) macro set serves a very narrow domain: documentation, i.e. manual pages. It's intentionally neither configurable nor extensible. The goal is to enforce a uniform style on manual pages, optimized for simplicity, conciseness, and clarity, but without manual page authors having to worry about the styling at all, in fact not even allowing authors to mess with that uniform style of manual pages, such that all pages follow the same conventions and readers can quickly become familiar with these conventions. > If I'm wrong, I might start writing my books in mdoc(7). Please don't even try. Writing a book in mdoc(7) is completely impossible for lots and lots of reasons. For a book, i guess that the groff_mom(7) macro set might be useful. Yours, Ingo
Re: Tools for writers
Hi, Martijn van Duren wrote on Wed, Nov 06, 2019 at 06:40:51AM +0100: > On 11/6/19 12:07 AM, Steve Litt wrote: >> On Tue, 5 Nov 2019 23:12:52 +0100 >>> https://www.openbsd.org/papers/bsdcan18-mandoc.pdf >> If the preceding presentation was authored in mdoc(7), could you please >> post the mdoc code that created it, and the mandoc(1) command and any >> filter programs that caused it to be a presentation instead of a man >> page? > You mean this one? > https://www.openbsd.org/papers/bsdcan18-mandoc.roff Exactly. Note that it does not use mdoc(7), though, but textproc/gpresent (groff_present(7)) on top of groff_mm(1) and roff(7). The mdoc(7) macro set has a very narrow scope: documentation. It isn't adequate for anything else, in particular neither presentations nor books nor even short journal articles. On the other hand, roff(7) can be used for any kind of typesetting, usually with one of the other macro sets. The most modern and most actively maintained of the general purpose macro sets is Peter Schaffter's groff_mom(7). Also note that i did not say pandoc is useless; all i intended to say is that if you need to write documentation, *that* is not a good reason to look at pandoc - merely because somebody on this list recommended pandoc specifically for writing documentation, which seems very misleading to me. > There are more examples at: > https://www.openbsd.org/events.html True. When it comes to gpresent, examples are arguably easier to find in this shorter list: http://mandoc.bsd.lv/press.html Yours, Ingo
Re: Tools for writers
On 11/6/19 12:07 AM, Steve Litt wrote: > On Tue, 5 Nov 2019 23:12:52 +0100 > Ingo Schwarze wrote: > > >> https://www.openbsd.org/papers/bsdcan18-mandoc.pdf > > If the preceding presentation was authored in mdoc(7), could you please > post the mdoc code that created it, and the mandoc(1) command and any > filter programs that caused it to be a presentation instead of a man > page? You mean this one? https://www.openbsd.org/papers/bsdcan18-mandoc.roff There are more examples at: https://www.openbsd.org/events.html martijn@
Re: Tools for writers
Dear Ingo, > Could I have a copy of the source text file of the presentation and the > command line(s) that produced the PDF file? I found it: https://www.openbsd.org/papers/eurobsdcon2018-mandoc.roff Yours sincerely, Xianwen
Re: Tools for writers
Dear Ingo, > The following presentation also contains a few related remarks > on pages 32-34, especially on page 33: > > https://www.openbsd.org/papers/bsdcan18-mandoc.pdf I read through the entire presentation for the sake of seeing what kind of presentation mdoc could produce. The presentation looked nice. Could I have a copy of the source text file of the presentation and the command line(s) that produced the PDF file? Yours sincerely, Xianwen
Re: Tools for writers
On Tue, 5 Nov 2019 18:38:03 +0100 Ingo Schwarze wrote: > Hi, > > Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: > > [ Pandoc ] > > is one of the most useful tools I have ever used. If you are > > writing any sort of documentation then I *highly* recommend > > checking it out > > I strongly oppose that point. I'm not a fan of pandoc either. It's a little too black-boxy for my taste. > There is no need at all to bother > with pandoc when you write documentation. (It may be useful for > other purposes, i have no idea). > > If you write documentation, just use the best format in the first > place. If the project you are documenting allows checking in > documentation in mdoc(7) format, use that. TL/DR SUMMARY: mdoc(7) is cool, but based on an hour or so's research is insufficient for all but the simplest full length books. I've spent the last hour or so looking at man pages mandoc(1) and mdoc(7), and I currently don't see how a non-simple book could be authored in mdoc(7). First of all, I see no method of creating a header hierarchy like ... or \part ... \subparagraph . I'd suspect it could be done by nesting .Sh lines, but I couldn't see how that could be done. As far as I can tell, mdoc(7) has no way to declare arbitrary styles. If I want a style called "stories", as an author I should be able to use one, and worry about semantic to presentational conversion of the stories style to be something I make later (with CSS or LaTeX or whatever). Almost by definition, if I can't create new semantic styles, I'll need to use or reuse predefined ones, which introduces ambiguity and mixing of semantic and presentational. Kudos for provisions to make a bibliography, and a TOC in HTML output. mdoc(7) supported lists cover a wide variety of presentations, but as far as I can tell you can't make new kinds of lists based on the existing lists. For instance, I might have a list for people with vertical spacing very different from a list for concepts, and I see no way to do that in mdoc(7) without declaring that all people are done with one kind of mdoc(7) list, and all concepts are done with another. Another problem: If I initially do both people and concepts with a certain mdoc(7) list type, and then decide people should look different, I'd have to search out all the people, instead of changing one line of CSS or one line of LaTeX. Based on my hour or so research, I don't understand how mdoc(7) would be a good authoring format for anything but the simplest book length document. If I'm wrong, I might start writing my books in mdoc(7). SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: Tools for writers
On Tue, 5 Nov 2019 23:12:52 +0100 Ingo Schwarze wrote: > https://www.openbsd.org/papers/bsdcan18-mandoc.pdf If the preceding presentation was authored in mdoc(7), could you please post the mdoc code that created it, and the mandoc(1) command and any filter programs that caused it to be a presentation instead of a man page? Thanks, SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: Problems with route installation to fib from OSPF
On Thu, Oct 24, 2019 at 02:09:09PM +0200, Joao Alves wrote:
> Hi Remi,
>
> I've installed a lab with OpenBSD6.6 VM's to see if would happen in the
> newer version.
>
> I was able to reproduce it again, but in slightly different manner.
>
> First of all, you need to have BGP running in FW's also, and have the
> same route received through BGP, otherwise the issue is not
> reproducible, because the MPATH flag will behave well with OSPF only.
> Without the MPATH issue you can't reproduce the rest.
Can you also reproduce without BGP but with a static route added like this:
route add -net 10.10.10.10 -netmask 255.255.255.255 192.168.98.204 -priority 40
>
> So LAB setup(all openbsd6.6 VM's):
>
> 2x fw/router
Can you also reproduce with only 1 fw or are both fw nodes needed to reproduce?
> 2x host
> 1x bgp router
>
> fw1:192.168.98.200
>
> fw2:192.168.98.201
>
> host1:192.168.98.202
>
> host2:192.168.98.203
>
> bgp:192.168.98.204
>
>
> In the hosts I run carp with VIP 10.10.10.10/32, carp configured with
> preempt in kernel.
>
> ospf config for host1/2 is (only router id change):
>
> host1# more
> /etc/ospfd.conf
>
>
>
>
> # $OpenBSD: ospfd.conf,v 1.2 2018/08/07 07:06:20 claudio Exp $
>
> # macros
> id="192.168.98.202"
>
> # global configuration
> router-id $id
> # fib-update no
> # stub router no
> # spf-delay 1
> # spf-holdtime 5
>
> # auth-key secret
> # auth-type simple
> # hello-interval 10
> metric 10
> # retransmit-interval 5
> # router-dead-time 40
> router-priority 0
> # transmit-delay 1
>
> # rtlabel "DMZ" external-tag 1
>
> # areas
> area 0.0.0.0 {
> interface em0 {
> auth-type simple
> auth-key secret
> }
>
> interface carp1 {
> passive
> }
> }
> host1#
Please show the configs of em0 and carp1.
>
> For FW1/2 is(router ID and router priority change, in FW2 priority is
> 10, so BDR):
>
> fw1# more
> /etc/ospfd.conf
>
>
>
>
> # $OpenBSD: ospfd.conf,v 1.2 2018/08/07 07:06:20 claudio Exp $
>
> # macros
> id="192.168.98.200"
>
> # global configuration
> router-id $id
> # fib-update no
> # stub router no
> # spf-delay 1
> # spf-holdtime 5
>
> # auth-key secret
> # auth-type simple
> # hello-interval 10
> metric 10
> # retransmit-interval 5
> # router-dead-time 40
> router-priority 100
> # transmit-delay 1
>
> # rtlabel "DMZ" external-tag 1
>
> # areas
> area 0.0.0.0 {
> interface em0 {
> auth-type simple
> auth-key secret
> }
> }
> fw1#
>
> For BGPD configs:
>
> FW1/2:
>
>
> fw1# more
> /etc/bgpd.conf
>
>
>
>
> # $OpenBSD: bgpd.conf,v 1.15 2018/11/17 17:22:38 deraadt Exp $
> # example bgpd configuration file, see bgpd.conf(5)
>
> # define our own ASN as a macro
> ASN="65123"
>
> # global configuration
> AS $ASN
> router-id 192.168.98.200
>
> # list of networks that may be originated by our ASN
> prefix-set mynetworks { \
> 192.0.6.0/24 \
> 2001:db8:abef::/48 \
> }
>
> # define bogon prefixes which should not be part of the DFZ
> prefix-set bogons {
> 0.0.0.0/8 or-longer # 'this' network [RFC1122]
> 10.0.0.0/8 or-longer # private space [RFC1918]
> 100.64.0.0/10 or-longer # CGN Shared [RFC6598]
> 127.0.0.0/8 or-longer # localhost [RFC1122]
> 169.254.0.0/16 or-longer # link local [RFC3927]
> 172.16.0.0/12 or-longer # private space [RFC1918]
> 192.0.2.0/24 or-longer # TEST-NET-1 [RFC5737]
> 192.88.99.0/24 or-longer # 6to4 anycast relay [RFC7526]
> 192.168.0.0/16 or-longer # private space [RFC1918]
> 198.18.0.0/15 or-longer # benchmarking [RFC2544]
> 198.51.100.0/24 or-longer # TEST-NET-2 [RFC5737]
> 203.0.113.0/24 or-longer # TEST-NET-3 [RFC5737]
> 224.0.0.0/4 or-longer # multicast
> 240.0.0.0/4 or-longer # reserved for future use
> ::/8 or-longer # RFC 4291 IPv4-compatible,
> loopback, et al
> 0100::/64 or-longer # Discard-Only [RFC]
> 2001:2::/48 or
Re: Tools for writers
Marc Chantreux wrote on Tue, Nov 05, 2019 at 07:56:03PM +0100: > can you explain us what's so wrong with keeping > simple things simple the way markdown allows us? https://undeadly.org/cgi?action=article&sid=20170304230520 The following presentation also contains a few related remarks on pages 32-34, especially on page 33: https://www.openbsd.org/papers/bsdcan18-mandoc.pdf Nothing is wrong with trying to make things simple for users, quite to the contrary. But that is not an excuse for delivering solutions that are technically abominable. When a language is technically as ill-designed as markdown is, the multitude of resulting traps actually makes it very hard to use, *not* easy at all. Yours, Ingo $ mandoc -mdoc -T ascii .Bl -bullet -compact .It Cynthia .It Werner .It Kristaps .El ^D UNTITLED LOCALUNTITLED o Cynthia o Werner o Kristaps November 6, 2019
Re: Tools for writers
> > > documentation language, mdoc(7), at all, neither for input nor for
> > > output, already makes me raise an eyebrow or two
> Vim has many useful HTML plugins (or write your own)
yes ... but why should i bother with an uggly distracting format when
i can have a format that is close visually to the idea i have in mind
(a list). also i made other points that aren't adressed by vim plugins.
> The above list require two keystrokes and a number of list items wanted
> in one plugin I have barely started to use.
yet another plugin to install, maintain and learn when i can rely on
external commands i can use in other contexts;
> A print CSS file can do a tremendous amount of formatting useful for
> printed documents.
what if you want to use music cheets, chemical structures, good looking
math formula or other material. latex comes with tikz, beamer, qtree,
all those things that makes good looking printed documents much easier
to produce ...
html is when i need interactivity or animation but it's always a
painful process to me. but the point of using markdown remains:
* brian
* ken
* doug
is easier to write, read and edit than
\begin{itemize}
\tightlist
\item
brian
\item
ken
\item
doug
\end{itemize}
or
brian
ken
doug
> I detest Libreoffice. I have never yet gotten it to do anything I
> needed.
so do i: i was interested by arguments against markdown.
> But to each their own. Overall, this thread has been very enlightening
> for me. I do need to learn some other methods. TeX and LaTeX keep coming
> up everywhere I look.
i have to admit i started using both html and latex at the same time and
prefered html at the begining. but with time, latex is much more
rewarding when it comes to printed docs.
the only format that made me really unhappy for the moment is troff but
i still hope i'll have fun with it at some point.
regards
marc
Re: Tools for writers
On Tue, Nov 05, 2019 at 07:56:03PM +0100, Marc Chantreux wrote: > > there is no problem with other formats but can't you admit that for many > people, something like > > * denis > * brian > * doug > > is easier to write, read and edit than << ? > > > denis > brian > doug > > > also: > > * transpiling is always a good thing to catch and avoid errors. for > exemple: did you realize that the "brian" item is broken? this will > not happen using a markdown as source > * the "proper" way to serialize an html/xml that is not intended to be > edited isn't the way i write above but this below instead. and frankly > i don't want to edit those kind of stuff > > denisbriandoug > > > The fact that pandoc appears to not support the most important > > documentation language, mdoc(7), at all, neither for input nor for > > output, already makes me raise an eyebrow or two Vim has many useful HTML plugins (or write your own) The above list require two keystrokes and a number of list items wanted in one plugin I have barely started to use. A print CSS file can do a tremendous amount of formatting useful for printed documents. * brian Has no formatting. Once again, we are talking ed(1). Followed by a formatter. I use vim on my laptop and ed(1) on my phone. It works. I detest Libreoffice. I have never yet gotten it to do anything I needed. But to each their own. Overall, this thread has been very enlightening for me. I do need to learn some other methods. TeX and LaTeX keep coming up everywhere I look. Have fun, Chris Bennett
Re: Tools for writers
On 05/11/2019 17:38, Ingo Schwarze wrote: Hi, Hello Ingo! Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: [ Pandoc ] is one of the most useful tools I have ever used. If you are writing any sort of documentation then I *highly* recommend checking it out I strongly oppose that point. There is no need at all to bother with pandoc when you write documentation. I think you shoud re-read that, especially the second sentence. Do you realize how ridiculous it is? Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Tools for writers
hello, > > that said: i'll really give troff a try again when i will figure out how > > to create templates for the documents i need (as i said in a previous > > message: i have a layout problem) > > First mention of templates in this four dozen message thread. i replied to this thread but as it was another branch, i changed the subject and the "in reply to" is the id of the original author. sorry if it wasn't the expected behavior. https://marc.info/?l=openbsd-misc&m=157293688812513&w=2 > What templates? template or macros: i don't know the good way to do it. the idea is to have the layout used in my organization so i can generate some reports using troff to generate pdf. this would be awesome but setting up a page layout is out of my scope and i haven't found a didactic documentation to just dive in the problem. any help would be much welcome. regards, marc
Re: new rust-libtls crates
On 17:33 Sat 02 Nov, Reyk Floeter wrote: > Why libtls? Because it is a sane TLS API with secure defaults. I > trust the decisions of the LibreSSL developers and libtls provides > some the best defaults. > > The code works on OpenBSD and Linux. Many distributions such as > Ubuntu don't seem to provide LibreSSL packages, so the very nice > libtls API is not available for them. My crate tries to download, > build, and link LibreSSL statically if it is not found. A bit of an offtopic, but most of the time people revert back to OpenSSL due to lags in API compatibility between the two projects. Maybe it would be better to provide libtls as a standalone library that can coexist with OpenSSL. E.g. install libssl.so and libcrypto.so as libressl.so and librecrypto.so and make libtls.so depend on them instead of libssl.so and libcrypto.so.
Re: Tools for writers
Am Mo., 4. Nov. 2019 um 09:39 Uhr schrieb Roderick : > TeX produces dvi, a well documented and simple page description language. > Then it is transformed to postscript or pdf. Nope. pdfTeX was developed 25 years ago, LuaTeX 12 years ago. Both write PDF directly. Best Martin
Re: Tools for writers
On Tue, Nov 5, 2019 at 1:58 PM Marc Chantreux wrote: > yes ... what's the point of using another format than postscript > directly. ... That's not a really question (nor does it fit here). > that said: i'll really give troff a try again when i will figure out how > to create templates for the documents i need (as i said in a previous > message: i have a layout problem) First mention of templates in this four dozen message thread. What templates? Thanks, -- Raul
Re: Tools for writers
Hi Ingo Many thanks for your inputs concerning older, but interesting tools g/t-roff and refer(1). I didnt know them before. -oliver On 3 Nov 2019, at 16:41, Ingo Schwarze wrote: Hello, Xianwen Chen wrote on Sun, Nov 03, 2019 at 04:16:43PM +0100: I am interested in giving _groff_ and _gpresent_ a try. I am seasoned LaTeX user. Is there a tutorial that you would recommend to someone like me? No, i'm not aware of tutorials (but i generally don't use tutorials, so maybe i missed them). But there is good reference documentation: https://www.gnu.org/software/groff/manual/html_node/ Gpresent is a macro package specifically for presentation slides. The documentation is in the groff_present(7) and presentps(1) manual pages in the textproc/gpresent package and in the groff_mm(7) manual page in the textproc/groff package. Two things that come to my mind that I am concerned with. First, how does groff manage bibliography and citations? See the refer(1) utility in the textproc/groff package. Second, peer-reviewed journals usually require submissions to be in Word format or in LaTeX. Is there an easy way to convert a groff document to a Word document or LaTeX? No, and there isn't even a complicated way either. If your publisher requires LaTeX, use LaTeX; it's really that simple... Yours, Ingo
Re: Tools for writers
hello, > > is one of the most useful tools I have ever used. If you are writing > > any sort of documentation then I *highly* recommend checking it out > I strongly oppose that point. There is no need at all to bother > with pandoc when you write documentation. (It may be useful for > other purposes, i have no idea). yes ... what's the point of using another format than postscript directly. also: using an high level language instead of writing everything in assembly is a chance to lose control over what you're writing. live is long enough to waste time ... i would like to suggest 2 reasons to use pandoc (and the markdown format): it will make the edition and the review of the document much more * easier * inclusive (people are able to read markdown format... but latex, html or troff is too much for lot of people) that said: i'll really give troff a try again when i will figure out how to create templates for the documents i need (as i said in a previous message: i have a layout problem) > The worst one > which you must avoid at all cost is DocBook, closely followed > by Markdown and related formats. agree for docbook but can you explain us what's so wrong with keeping simple things simple the way markdown allows us? i personally prefer textile but markdown became kinda defacto wiki syntax standard with lot of variations. i really like to use human readable formats so markdown and yaml became formats i use every day and enjoy it. > So, when talking about documentation, i have never encountered any > problem that even made me look at pandoc, there is no problem with other formats but can't you admit that for many people, something like * denis * brian * doug is easier to write, read and edit than << ? denis brian doug also: * transpiling is always a good thing to catch and avoid errors. for exemple: did you realize that the "brian" item is broken? this will not happen using a markdown as source * the "proper" way to serialize an html/xml that is not intended to be edited isn't the way i write above but this below instead. and frankly i don't want to edit those kind of stuff denisbriandoug > The fact that pandoc appears to not support the most important > documentation language, mdoc(7), at all, neither for input nor for > output, already makes me raise an eyebrow or two please contribute :) also: the support of troff was removed from graphviz many years ago. how sad is it? > did, i still wouldn't see what it could possibly be useful for. you don't have non technical colleagues, don't you ? Sincerely marc
Re: libcrypto.so.46.0 warning after downgrade
Dieter Rauschenberger wrote: > Mi misc, > > I had to downgrade to a former snapshot one week old. No matter how often we tell people "you can't do that without consequences" there is always someone who tries. Upgrades that move forward work. Upgrades that go backwards, will break in unanticipated ways. Step back for a second. Do you think any of our developers ever do this? No. So why do you think you are in the clear? > Now I get the > following warning on programs useing libcrypto: > > warning: libcrypto.so.46.0: minor version >= 1 expected, using it > anyway > > A reboot does not help. > How to fix this? Upgrade to a newer snapshot. Isn't it obvious?
Re: Tools for writers
Hi, Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: [ Pandoc ] > is one of the most useful tools I have ever used. If you are writing > any sort of documentation then I *highly* recommend checking it out I strongly oppose that point. There is no need at all to bother with pandoc when you write documentation. (It may be useful for other purposes, i have no idea). If you write documentation, just use the best format in the first place. If the project you are documenting allows checking in documentation in mdoc(7) format, use that. If the project also wants to cater for systems not supporting formatting of mdoc(7) documents (basically, system providing neither groff nor mandoc, which more or less boils down to some old commercial UNIXes), use mandoc(1) -T man at release tarball build time to produce man(7) versions of the mdoc(7) files and ship them in the release tarball, too. If the project you want to document does not allow checking in mdoc(7) files, write your documentation in perlpod(1). The widely available pod2man(1) tool converts perlpod(1) to high quality man(7) output. If, at some time, you want to upgrade to mdoc(7), the pod2mdoc(1) tool helps a lot with that conversion. If the project you want to document neither allows checking in mdoc(7) nor perlpod(1) sources, write your documentation with groff_man(7). Doing that well is admittedly harder than writing good mdoc(7) or perlpod(1) and results in somewhat lower output quality, but it's not rocket science either. Using any other format is a thoroughly bad idea. The worst one which you must avoid at all cost is DocBook, closely followed by Markdown and related formats. So, when talking about documentation, i have never encountered any problem that even made me look at pandoc, and i'm working on documentation a lot, including format conversions. The fact that pandoc appears to not support the most important documentation language, mdoc(7), at all, neither for input nor for output, already makes me raise an eyebrow or two, but even if it did, i still wouldn't see what it could possibly be useful for. Yours, Ingo
libcrypto.so.46.0 warning after downgrade
Mi misc, I had to downgrade to a former snapshot one week old. Now I get the following warning on programs useing libcrypto: warning: libcrypto.so.46.0: minor version >= 1 expected, using it anyway A reboot does not help. How to fix this? Regards Dieter
Re: support new
To quote my earlier answer: > Please go away. > > If somebody needs half a dozen tries before they manage to send an > email, that person is not qualified to help others with computers. I don't think we should add a link from the OpenBSD website to your company. ibrahim topbasi wrote on Mon, Nov 04, 2019 at 09:34:46PM +0100: > 0 > C Turkey > P Ankara > T Cankaya > Z 06510 > O Rakort Information Technologies & ibrahim TOPBASI > I Rakort Information Technologies > A 2139. Street 2/11 > M ibrahimtopb...@mail.com > U http://www.rakort.com > B +90-532-633-17-92 > X > N More than 5 years, OpenBSD setup/installation/remote administration. > Network engineering, software development. Also experienced with > Solaris and Linux. We specialize in providing open source solutions > for businesses using OpenBSD and Linux. CCNP, RHCE certifications, > VPNs, firewalls, wireless, DNS, squidGuard, mail - even training with > OpenBSD. We have more then 5 years experience with the OpenBSD > platform and are able to deliver 24/7 solutions with necessary SLA's.
support new
0 C Turkey P Ankara T Cankaya Z 06510 O Rakort Information Technologies & ibrahim TOPBASI I Rakort Information Technologies A 2139. Street 2/11 M ibrahimtopb...@mail.com U http://www.rakort.com B +90-532-633-17-92 X N More than 5 years, OpenBSD setup/installation/remote administration. Network engineering, software development. Also experienced with Solaris and Linux. We specialize in providing open source solutions for businesses using OpenBSD and Linux. CCNP, RHCE certifications, VPNs, firewalls, wireless, DNS, squidGuard, mail - even training with OpenBSD. We have more then 5 years experience with the OpenBSD platform and are able to deliver 24/7 solutions with necessary SLA's.
