As much as saying this is probably going to get me a lot of hate from web developers, the world needs more browser engines. Simpler ones, maybe HTML+CSS only with no scripting. The idea of the Web as a flexible hyperlinked document system and not an application platform needs to gain more support. IMHO if your site is information-centric, and it's not readable in these "document-only" browsers, you're doing it wrong.
I don't understand this hatred of Javascript. The only websites I've felt were actually bloated are news sites with a lot of ads, but that's not a problem with Javascript as much as it is a problem with excessive ads.
What counts as information-centric? A lot of basic things (commenting, searching, liking a post) require Javascript. If you want to use pretty animations, there's a high probability you need Javascript.
Making information-centric sites only use HTML/CSS would significantly decrease the capabsilities and attractiveness of the sites.
> The only websites I've felt were actually bloated are news sites with a lot of ads, but that's not a problem with Javascript as much as it is a problem with excessive ads.
The problem is JS has too much power in the browser, and too little consideration for security. It can effectively take control away from the user, there's virtually no way to know what it's doing without source code audits, which are prohibitive, and the security vulnerabilities are legion.
> What counts as information-centric? A lot of basic things (commenting, searching, liking a post) require Javascript.
> > What counts as information-centric? A lot of basic things (commenting, searching, liking a post) require Javascript.
> None of these actually require JS.
Can you imagine a facebook doing a page reload/refresh every time you click to like a post? Or without loading more content on demand every time you scroll the page?
> Can you imagine a facebook doing a page reload/refresh every time you click to like a post?
You're stuck thinking about Facebook as if it still had long lists of posts with infinite scroll. The UX would be completely different when the design constraints are different.
For instance, instead of infinite scrolling, you might show one post at a time with clickable previews of the last and next posts. A like doing a full postback isn't a big deal with this approach, particularly with judicious use of anchors. Certainly not as slick, but perfectly usable.
Put me in the group of users who despise infinite scrolling --- I would much prefer a paged interface (like the way it was before IS became popular) because it gives you a sense of where you are, and more importantly, an O(1) way to resume where you left off.
(I suppose the companies like IS because it has an addictive property, but I suspect me and others who see through that don't like it at all. Relatedly, the other popular concept of a "feed" also conjures up images of farm animals munching away at a trough; perhaps that is the real intent...)
A slightly worse user experience on Facebook, for a significantly better and more secure user experience on the web overall. I'm not sure that's such a terrible tradeoff.
Agreed on built-in browser behaviour though. Chrome pushing more input types a few years ago was a great thing.
Making information-centric sites only use HTML/CSS would significantly decrease the capabsilities and attractiveness of the sites.
For me, and probably many others, the "attractiveness" of sites that don't use JS is far higher. Searching the Web for information with JS enabled is like visiting a library full of books that will randomly turn their pages, jump around, and scream at you like those in the Harry Potter world.
Intrusive ads are a problem, but not the only problem.
My basic issue with JavaScript is when it's used to move stuff around after the page is done loading, or when it significantly delays when loading finishes.
Voting on posts, and well done search autocomplete can be nicely done with JavaScript, commenting itself works fine without (I don't think there's anything JavaScript where I'm writing this?)
Somedays it feels like I spend as much time waiting for pages to load in 2018 as I did in 2000, and pages certainly look prettier, but don't impart any more information.
I started a weblog a couple of days ago, and the joy of publishing generated markdown documents on a fileserver is as big as any of my JavaScript ventures.
You didn’t answer the question. All you did is try to misdirect the discussion.
I think he has a valid question. I’m in the market for a replacement for my Onion Omega2’s, so I clicked the link. The fact that the product page is exclusively in Chinese does not make me confident.
Western bias? Maybe. But that doesn’t mean the concern isn’t valid. I’d worry if it was in Russian, too.
i think your concern should be relative to your value as a target of a hack. there's a reason billionaires have private bodyguards and we don't, and there's a reason high value systems are built from scratch in tightly controlled environments and use things like hardware based security
In my university,my professor told us about the existance of this proof in December,and that he gave a presentation that time.So i guess it has been reviewed thoroughly.
same pkgsrc checkout + reproducable base
=> essentially reproducable full package builds.
yes, some people will find some niggling way to make this not true because the binaries may be somehow altered due to timestamps, yadda, but for all practical purposes w/r/t the actual code and actual executables generated, this is true,
and has been true for essentially the entire existance of bsd derivitaves using ports systems (1996).
> same pkgsrc checkout + reproducable base => essentially reproducable full package builds.
I would be truly surpised if that were the case. Are there no packages in pkgsrc which embed, e.g. timestamps, or even download things while building[1]?
[1] JDK packages are a typical culprit in this type of situation because Oracle JDK requires an "accept license" prompt.
> es, some people will find some niggling way to make this not true because the binaries may be somehow altered due to timestamps, yadda, but for all practical purposes w/r/t the actual code and actual executables generated, this is true, and has been true for essentially the entire existance of bsd derivitaves using ports systems (1996).
Oh, so you're coopting "essentially reproducable" to mean "not reproducible". Ok then.
"Reproducible builds" is about verification and isn't just about "close enough".
The only good reason I can think of to support something other than x86_64 is running on something like a raspberry pi or some sort of 'embedded' device. That's not really suited to the goals of Dragonfly anyways, NetBSD or Linux are a much better fit there.
Well yes because Dfly has really small community compared to even FreeBSD .. supporting/testing multiple architectures is a monumental task for distro maintainers.
I have read it but in the past he wrote a blog post that risc-v will be used as isa in future products.So maybe 64 bit risc-v with backwards compatibility with epiphane?(it sounds a bit strange)
I have two excuses for why RISC-V didn't make it it. My February RISC-V post stated that we will use RISC-V in our next chip. We were already under contract for this chip so I was referring to the next chip from now. I had hopes of sneaking it into this chip, but ran out of time. Both lame excuses, I know. I am firmly committed to RISC-V in some form in the future. For clarity, I am not talking about replacing the Epiphany ISA with a RISC-V ISA.
Agree, but people have all kinds of pre-conceived notions about co-processors so let's clarify some things: e5 can't self-boot, doesn't have virtual memory management, and doesn't have hardware caching, but otherwise they are "real" cores. Each RISC core can run a lightweight runtime/scheduler/OS and be a host.
Jan Gray stuffed 400 RISC-V cores into a Xilinx Kintex UltraScale KU040 FPGA (and the KU115 is three times larger, not to mention the Virtex UltraScale range).
I think a heterogeneous product was implied in that post, but I don't blame you for the confusion. The Epiphany-V is still homogeneous because of the time/funding constraints.
Getting ready to share some good news on the project in the coming couple of days regarding the successful integration to it's launch system and some details on the launch and delivery to ISS.
