Le 27-05-2013 02:48, Carlos Torres a écrit :
sbase and 9base are still used. i use 9base every day :).
Ah, nice. It's awesome.
not much work goes into these since they don't
aspire to having all the gnu options... what more do you need?
Actually, I'm trying to find a coreutils/busybox alternat
On Sun, May 26, 2013 at 3:21 PM, Dmitrij Czarkoff wrote:
> How does this problem differ from downloading a file from URI in IRC chat or
> from mail? Why should it be solved differently in browser then?
Doesn't have to be solved differently, but then, for the sake of
convenience, network efficienc
On 2013-05-27, at 12:12, Fernando C.V. wrote:
> Either that or you will need a video player that speaks http.
Which they usually do. It's called streaming and has been popular for roughly
15 years.
-Truls
On May 27, 2013 12:23 PM, "Truls Becken" wrote:
>
> On 2013-05-27, at 12:12, Fernando C.V. wrote:
>
> Which they usually do. It's called streaming and has been popular for
roughly 15 years.
Ambiguous jargon: RTP, plain HTTP and flash are all called streaming in
different contexts.
Dmitrij D
Dnia , o godz.
Random832 napisał(a):
> On 05/25/2013 12:55 AM, Strake wrote:
> > Yes. Thus I can easily swap out any component, or insert mediators
> > between components. For example, I could write my own fetcher to
> > scrub the HTTP headers, or block ads; and I wouldn't need plug-ins
> > to
On May 27, 2013 12:12 PM, "Fernando C.V." wrote:
>
> Normally this means (for videos at least), the link is actually a html
> page with a flash plugin or a tag. Either that or you will
> need a video player that speaks http.
There can be a gentler solution similar to the way some network protoco
On Mon, May 27, 2013 at 12:38 PM, Dmitrij Czarkoff wrote:
> There can be a gentler solution similar to the way some network protocols
> are handled in FUSE, Plan 9 and HURD: they create a pseudo fs and let normal
> file I/O on it. *Much* cleaner approach IMO.
On Mon, May 27, 2013 at 12:34 PM, Had
Type safety/constraints on HTTP request parameters would make HTTP less
insecure. Is there HTTP server software out there doing this today?
//SC
On 27 May 2013 19:43, Sebastian Cato wrote:
> Type safety/constraints on HTTP request parameters would make HTTP less
> insecure.
No, it wouldn't. It might provide a false sense that that improves
security, but it doesn't actually improve the situation.
Somebody signing messages as Nicolas Braud-Santoni wrote:
Well, SFTP requires you to create a user account. (I'm aware that it may
not be one with which you can SSH in).
The OpenSSH implementation more-or-less requires that (though it's really
not a big deal), but the protocol does not require
Please motivate why it wouldn't improve security.
On 28 May 2013 00:11, Sebastian Cato wrote:
> Please motivate why it wouldn't improve security.
Because the majority of HTTP security problems would not be solved by
having types. Why do you think it would?
I believe it already has what you need to replace coreutils/busybox.
though its not just a matter or swapping stuff. you'ld have to port
all the shell scripts that depend on gnuish stuff. i.e. anything that
uses the auto* stuff doesn't work with 9base awk and ls... but do you
really need stuff th
Greetings.
On Mon, 27 May 2013 20:21:24 +0200 "Fernando C.V." wrote:
> On Mon, May 27, 2013 at 12:38 PM, Dmitrij Czarkoff wrote:
> > There can be a gentler solution similar to the way some network protocols
> > are handled in FUSE, Plan 9 and HURD: they create a pseudo fs and let normal
> > file
Le 27-05-2013 20:14, Carlos Torres a écrit :
I believe it already has what you need to replace coreutils/busybox.
though its not just a matter or swapping stuff. you'ld have to port
all the shell scripts that depend on gnuish stuff. i.e. anything that
uses the auto* stuff doesn't work with 9bas
sbase and 9base overlap a bit on functionality. sbase is better
suited for core. though currently it seems you should layer sbase on
top of 9base to fulfill some of sbase's TODO's. get porting :)
--Carlos
On Mon, May 27, 2013 at 3:01 PM, Hugues wrote:
> Le 27-05-2013 20:14, Carlos Torres a éc
On May 27, 2013 8:25 PM, "Christoph Lohmann" <2...@r-36.net> wrote:
>
> Surf is waiting for someone to write a suckless rendering engine. Then
> the HTTP transfer functions can be done through some filesystem.
I wouldn't bet on seeing suckless rendering engine anytime soon. Actually,
the amount
Quoth Dmitrij Czarkoff:
> I wouldn't bet on seeing suckless rendering engine anytime soon. Actually,
> the amount of insanity in web standards makes me think that more or less
> feature-complete rendering engine and suckless software don't belong to one
> set.
Netsurf's rendering libraries are pr
On Sun, May 26, 2013, at 9:21, Dmitrij Czarkoff wrote:
> May it owe to the fact that this particular IPC protocol is *the*
> protocol
> used for nearly all IPC in the system?
I have no idea what protocol you are talking about.
On May 27, 2013 11:13 PM, "Nick" wrote:
>
> Netsurf's rendering libraries are pretty suckless. But they don't
> have at all complete javascript / dom support yet, so it's only as
> useful as lynx (which is to say, rather useful, but not for
> everything that is convenient to do on the web).
NetSu
Dnia 2013-05-27, o godz. 23:32:48
Dmitrij Czarkoff napisał(a):
> On May 27, 2013 11:13 PM, "Nick" wrote:
> >
> > Netsurf's rendering libraries are pretty suckless. But they don't
> > have at all complete javascript / dom support yet, so it's only as
> > useful as lynx (which is to say, rather us
On May 27, 2013 11:53 PM, "Hadrian Węgrzynowski" wrote:
>
> For example support only two fonts: monospace and proportional.
And have some sites broken because the idiots who made them did some
pixel-exact fine tuning based on some particular font's properties. I still
hit the occasions when the r
Greetings!
I'm sending this mail to two lists -- CRUX and Suckless Developers, so some
things
may seem obvious, while others not.
Is it just me or is there any problems with how WebKitGTK is built from CRUX
ports?
So, I build WebKitGTK from this Pkgfile[0] and surf[1] from this one[2].
I have
23 matches
Mail list logo
